Сейчас проходит конференция Compile от Cursor, и одно выступление сразу попало в мою личную боль: кто я теперь? Если мы отождествляем себя через результат своего труда, то код – то, что мы пишем писали большую часть времени – уже не является произведением твоего умственного труда. Но все таки... Что сегодня представляет работа в ИТ?
Это перевод выступления и самостоятельно переведенные слайды. Далее повествование будет вестись от первого лица, чтобы не менять суть и нить. Часть текста я намеренно сократил, так как на мой взгляд оно не влияло на суть. Приятного чтения!
Фархан Тавар | Compile 26
Я руководитель инженерного направления в Shopify, и я хочу поразмышлять над одним вопросом: с приходом ИИ, который берёт на себя всё большую часть работы инженеров, что теперь является нашей работой? Потому что многое действительно изменилось — особенно в инженерии, но также во всём R&D и даже в других дисциплинах. Я хочу исследовать этот вопрос. Но прежде чем мы к нему перейдём, я хочу попросить о минуте молчания. Есть один твит, который по-настоящему меня задел.
Весь программный код, которым мы пользуемся в нашей жизни — включая многих из вас, и меня тоже, — был написан символ за символом. Удивительно осознавать, что всё, созданное до сих пор, было написано именно так. Минута молчания, немного грусти, потому что это то, как мы делали вещи в прошлом, и уже не то, как мы будем делать их в будущем. И я хочу разобраться, что изменилось.
Как меняется жизненный цикл разработки программного обеспечения
Если посмотреть на SDLC (жизненный цикл разработки программного обеспечения), то можно заметить: место, где мы тратим время, смещается. На диаграмме слева видно, что большинство времени уходило на написание кода. Конечно, время тратилось на планирование, проверку, тестирование и поддержку, но большой голубой блок — это был этап написания кода. На диаграмме справа этот этап радикально изменился: теперь вы будете больше времени тратить на использование инструментов для планирования и анализа, на проверку того, что выдают ИИ-инструменты.
Есть два подхода к этому новому этапу кодирования:
Параллельное кодинг. Разбиваете задачу на подзадачи, запускаеие на каждую из них агентов, а затем возвращаетесь, объединяете результаты и проводите валидацию.
Последовательные циклы тщательной оценки. Работаете в паре с одним ИИ по-настоящему глубоко, используете модель с расширенным рассуждением, привлекаете другую модель для проверки результатов.
Но в обоих случаях не обязательно, что именно вы пишете код. Вы работаете с ИИ-агентом и планируете, как создать что-то для пользователей.
Всё меняется, и то, как вы тратите время, тоже меняется. Отсюда и возникает вопрос: в чём теперь наша реальная работа? Оказывается, ценность смещается от человека, который вводил команды символ за символом в любимую IDE на любимом языке программирования, — к другим вещам: вкусу, суждению.
Когда стоит что-то написать? Зачем? Что именно? Как продумывать архитектуру того, что ты создаешь? Как глубоко понять проблему, много времени провести с клиентами, обдумать множество возможных решений.
В Shopify у нас есть такой вопрос: когда кто-то приносит нам решение, мы спрашиваем: «Круто, оно работает. Но как ты выбрал именно это из десяти тысяч возможных правильных решений? Как ты пришёл к этому?»
Обучение — это побочный результат
Реальная часть разработки программного обеспечения и работы с клиентами и командами — это процесс обучения. У нас есть показательная история об этом.
До эпохи больших языковых моделей у нас была довольно большая команда — около 50 инженеров — работавшая над одним из наших проектов. Они провели 18 месяцев, создавая что-то для наших продавцов. Когда мы были готовы к запуску, состоялся знаменитый ревью с Тоби — нашим основателем и генеральным директором. Мы провели его по архитектуре, показали всё, что построили. Он сказал: «Отлично, надо запускать».
Когда мы уже уходили из конференц-зала, он остановился и задал один вопрос: «А если бы вы начали всё сначала, как бы вы это построили?» Команда призадумалась. Потом кто-то подошёл к доске и сказал: «Зная всё, что я знаю сейчас, мы построили бы вот так» — и описал совершенно другую, значительно более простую архитектуру. Тоби сказал: «Ну так и постройте именно так».
Буквально произошёл разворот. Он сказал: «Просто удалите то, что сделали, и начните заново». Потому что он хотел показать нам: обучение — это и есть побочный результат, а не код. Мы не могли буквально удалить код. Вместо этого мы выработали правило: можно смотреть на старый код, но нельзя его копировать — потому что именно к этому тянет в первую очередь. И мы пересобрали систему за три месяца — получив гораздо более простое и элегантное решение. Потому что обучение — это побочный результат, а не код.
Узкое место всегда перемещается
Происходящее сейчас с изменениями ИИ в части рабочих процессов и SDLC — это история об узких местах. Есть замечательная художественная книга о человеке на заводе, который пытается оптимизировать разные этапы производства. Он устраняет одно узкое место, а потом замечает: появилось другое. Он устраняет следующее — появляется ещё одно. Так он оптимизирует завод шаг за шагом.
Именно это сейчас происходит: ИИ берёт на себя написание кода и перемещает узкое место в другие части SDLC. Пока вы планируете или проверяете результаты, узкое место где-то сместится — и это нормально. Вы просто будете находить и устранять его снова и снова. Ваша ценность никуда не делась. Просто узкое место теперь в другом месте.
Если проблема достаточно хорошо определена, нужно ли выбирать между двумя неделями и двумя месяцами? Может быть, они примерно одинаковы — ведь «кланкер» (как Тоби называет ИИ) напишет весь код.
Записка Тоби
В 2025 году Тоби опубликовал то, что мы называем «твитом, услышанным во всём мире»: ИИ станет базовым ожиданием от сотрудников Shopify. Любопытно было не то, что это был твит, который отражал внутренний меморандум. Любопытно было то, что технические директора и генеральные директора начали писать мне после публикации и делиться своими собственными версиями этого же сообщения внутри своих компаний. Потому что все хотели, чтобы люди понимали: мы хотим, чтобы вы умели пользоваться этим инструментом. Мы хотим, чтобы вы были «ИИ-рефлексивными».
Что это значит? ИИ-автоматизм — это минимальное расстояние между столкновением с проблемой и тем, чтобы потянуться к ИИ. Как быстро вы можете обратиться к ИИ? Как долго вы остаётесь в тупике, прежде чем подумаете: «Стоп, давай подключу ИИ»?
Реальные результаты: команда поддержки создала инструмент Scout, позволяющий задавать вопросы об обратной связи от клиентов. Продуктовые менеджеры используют его постоянно — смотрят, что сегодня больше всего раздражает продавцов. Команды по работе с клиентами создали ежемесячные и квартальные бизнес-обзоры с помощью Cursor. Финансовый отдел построил инструменты для прогнозирования.
Более подробно на английском: https://www.firstround.com/ai/shopify
Найм 1000 стажёров
В 2024 году у нас было 75 стажёров в Shopify. В 2025 и 2026 году — 1000.
Причина была не благотворительность. Некоторые говорят: «Это помощь сообществу, хороший опыт для стажёров». У нас было наоборот: мы хотели, чтобы они пришли и научили нас работать. Подумайте: выпускной класс 2026 года провёл весь колледж с ChatGPT или другим инструментом. Мы хотели, чтобы эти люди приходили в наши офисы и ставили под сомнение всё в том, как мы работаем. Мы хотели их голод, их интенсивность. Мы хотели изменить культуру компании.
Тысяча стажёров пришла. Многих из них мы наняли на полную ставку. Это отличный способ дать компании новый импульс и изменить культуру — не просто через мандат об ИИ-автоматизме, но и через тип людей, которые входят в компанию.
Идея «ИИ-кентавра» — человек + LLM вместе создают что-то лучшее — была с нами с 2021 по 2024–2025 год. К сожалению, это время прошло быстрее, чем хотелось бы. Это было удивительное время, когда мы могли работать в паре с ИИ, а ИИ всё ещё по-настоящему нуждался в нас для обсуждения и советов по коду.
Конец эпохи "кентавра"
В декабре 2025 года всё изменилось. Люди называют это «моментом Opus 4.5» или «моментом GPT 5.2». Во время рождественских каникул многие ведущие инженеры мира сказали: «Кажется, LLM пишет код лучше меня».
Это задело самую суть инженерного этоса
Моя работа — писать код. Всё в моей жизни и карьере связано с вводом символ за символом того, что машина превратит в машинный код и исполнит
А теперь ты становишься тем, кто направляет ИИ. Когда LLM пишет код лучше тебя, нужно сместить фокус туда, где теперь находится узкое место — не в написании кода, а в другой части пайплайна.
Это не значит, что люди никогда не должны писать код. Возможно, есть специфические вещи, с которыми LLM плохо справится. Но я убеждён: 90% и более кода во многих компаниях сейчас должен писать ИИ — просто потому что он делает это лучше.
Слово «токен-максинг» превратилось в существительное — люди просто используют токены снова и снова. Мы хотели двигаться от ИИ-автоматизма к ИИ-левериджу: не просто использовать ИИ для работы и устранения рутины, но и научить людей гордиться своей «ленью». «Я построил это за пять минут — это заняло бы пять месяцев». Мы хотели быть образцом для подражания и показывать, что возможно.
Что не изменилось? Закон Паркинсона: объём работы расширяется, чтобы заполнить выделенное для неё время. Если вы просите что-то к пятнице — это будет готово к пятнице. Но с ИИ больше не нужна дорожная карта на шесть месяцев. Мы спрашиваем: «Почему нельзя это сделать за месяц? За неделю? Сегодня?»
Обучение не изменилось. Код — не побочный результат, побочный результат — это обучение. Мы спрашиваем команды: что вы узнали на этой неделе? Что неочевидно? Что вы поняли, чего другие ещё не знают? Это то, что позволяет принимать лучшие решения на следующей неделе.
Парное программирование не изменилось. Есть вещи, которые ты узнаёшь вместе с другим человеком перед компьютером и LLM, которые не узнаешь с LLM в одиночку. Два человека, один компьютер — и LLM сверх этого. Суть не в строчках кода.
По метрикам, которые мы наблюдаем: количество PR на инженера растёт, сложность каждого PR растёт, длительность проектов сокращается, амбициозность проектов растёт. Лучший способ оценивать скорость разработки — еженедельные демо.
https://x.com/benrady/status/817430925176958977
Прототип — это не продакшн
Не путайте карту с территорией. Это происходит постоянно: руководитель что-то «вайб-кодит» и показывает:
Смотри, как легко! Я это создал! Почему нельзя просто задеплоить в продакшн?
Прототип — это не продакшн. У меня есть CEO, который пишет код. Он говорит то же самое: «Я только что создал это за пять минут. Почему у команды ушёл месяц?» — «Потому что прототип — это не production-качество кода». По-прежнему верно, ничего не изменилось.
Мы стараемся удалять код прототипа или не использовать его — это упражнение по исследованию, а не production-код. Пример: один из наших стажёров удалил шесть строк кода и сэкономил более 600 000 долларов в год на инфраструктуре. Покажите мне метрику, которая показала бы, что этот стажёр крут. Таковой нет. Невозможно управлять по таблицам.
Как Shopify работает с ИИ
Пять принципов того, как мы работаем с ИИ в Shopify.
🤖 Первое — выбор модели. Мы разрешаем инженерам использовать только самые большие и дорогие модели: Opus 4.5, GPT-5.5, Gemini 3.5. Мы не разрешаем использовать меньшие модели, потому что считаем: время человека стоит дороже, чем время «машины». Если человек использует меньшую модель и появляется баг, на его поиск уйдут часы — тогда как более мощная модель его бы не допустила.
🧑💻 Второе — узкое место находится в ревью кода. Генерируется огромное количество кода. Как его всё проверять? Четыре страшных буквы: LGTM — «Looks Good To Me». Каждый PR получает это, а потом всё равно может содержать проблему. Люди и раньше не были хороши в проверке кода. Поэтому мы используем «Совет LLM»: разные модели смотрят на разные части кода и проверяют разные аспекты — доступность, безопасность и другие характеристики. Не идеально? Конечно. Люди были идеальны? Тоже нет. До LLM ревью занимало 24–48 часов, теперь — час. LLM точнее.
✍️ Третье — ответственность. Мы не позволяем ИИ брать на себя ответственность в Shopify. Можно работать с LLM, можно заставлять его писать сколько угодно кода, проводить валидацию. Но ваше имя стоит на PR. Ответственность может быть разделена, но её нельзя передать.
🐣 Четвёртое — найм. Честно — мы понятия не имеем, как нанимать под ИИ. Думаю, никто не знает. Мне нравится такая модель: в Университете Ватерлоо на первом курсе математического факультета нам запрещали использовать калькулятор — мы учили всё вручную. На втором курсе калькулятор появлялся. По аналогии — три режима оценки при найме: без ИИ (разберитесь в основах), ИИ опционально (можете использовать), ИИ обязательно (задача слишком большая, времени мало — используйте инструмент). Это пропускает «вундеркиндов» — людей, которые, может, и не понимают код досконально, но умеют так управлять ИИ, что получают потрясающие результаты.
🕺Пятое — размер команды. «Можно ли сократить команду разработчиков?» Это самое смешное, что я слышу. «У нас 100 инженеров, давайте оставим 10». Это настолько неамбициозно. Мы думаем иначе: «У нас 3000 инженеров. Почему они не могут действовать как 100 000?» Вот наш принцип. Парадокс Джевонса: сделать что-то дешевле и доступнее — значит, что больше людей будут это использовать. Мы пытаемся решить проблему предпринимательства. Зачем нам сокращаться? Каждый может быть продуктивнее. Кто-то написал статью, что «за Shopify стоит 23 000 инженеров». Я думаю: мы примерно на четверти пути. Хочу, чтобы кто-то написал: «За Shopify стоит 100 000 инженеров».
Эпизод 10: Что изменилось, что осталось
Что изменилось: «машины» пишут и проверяют код — примите это. Вы будете тратить больше времени на другие части SDLC — планирование и валидацию. Возможно, изменится ваш кадровый микс. Я убедил Cloudflare нанять 1000 стажёров. Мэтт Гарман из AWS нанял 11 000 стажёров в этом году. Всё меняется на всех уровнях.
Что осталось: вкус и суждение. Вы всё ещё должны думать о том, что выходит к вашим пользователям — и у вас будет больше времени на это, потому что вы можете глубже погружаться в проблему. Оценивать производительность инженеров по-прежнему сложно. Никакой таблицей это не решить. Обучение по-прежнему остаётся целью. Не смотрите на побочные результаты. Не на код, не на количество отгрузок — на то, как быстро вы учитесь. Потому что вы можете использовать эти инструменты, чтобы создать что угодно так быстро, как захотите.
Ссылка на видео: https://www.youtube.com/watch?v=ByOF8qByGHU