Это начало серии. Расскажу о трансформации, которую мы начали в tech, в Prolog, месяца два назад: почему началось, что получается и что дорого обошлось. Это не теория со сцены. Это то, что мы прожили.
Решил написать по простой причине: когда я искал, как это сделать, я нашёл много мнений и мало честных рассказов от тех, кто был в самой гуще процесса. Если этот текст станет местом, на которое обопрётся другой человек, который строит, значит, оно того стоило.
Началось с дискомфорта.
Что я увидел
В марте мы с Jean, моим партнёром, поехали на SXSW, в Техас, один из крупнейших фестивалей инноваций в мире. Вернулся я другим, и дискомфорт не прошёл. Дело было не в том, что я видел на сцене. А в том, что я видел, как компании уже делают на практике.
Вернувшись, я нырнул в технический контент тех, кто и правда строит с ИИ там, за рубежом. Не в тёплый контент Instagram и LinkedIn. В глубокий, от тех, кто сам берётся за дело и публикует, чему научился. И натыкался на случай за случаем компаний, которые по-настоящему изменили способ работы. Разница тонкая и огромная одновременно: они не «начали использовать ИИ», они поставили ИИ в центр.
И это не отмахнуться как от хайпа со сцены. Это внедрение в промышленном масштабе: большие компании и маленькие, все идут в одно и то же место. Одна из вещей, что меня зацепила, была простая цифра: 9 из 10 компаний Fortune 100 уже внедрили Copilot. Но важна не цифра внедрения. А размер прироста. Те, кто просто впихнул ИИ в старый поток, сообщают о 10, 20% прибавки к продуктивности. Те, кто перестроил вокруг него, сообщают о кратном: 5x, 10x. Я раскрою эти случаи по одному в следующих статьях. Пока же интересен тот сдвиг, что есть у всех них общего.
Использовать сбоку vs. поставить в центр
Это различие кажется мелким, и именно оно решает всё.
Использовать ИИ, это открыть инструмент сбоку и идти по тому же процессу, что и раньше. Поток остаётся тем же, должности остаются теми же, review остаётся тем же. ИИ, это ещё одна вкладка, и каждый выкручивается с ней сам. Прирост появляется на полях.
Поставить в центр, это перепроектировать процесс вокруг него. Ты исходишь из того, что ИИ построит бо́льшую часть работы, и перестраиваешь поток, должности и review исходя из этого. Контекст перестаёт умирать в одном разговоре и становится общим. Прирост совсем другого порядка, потому что это не та же работа быстрее. Это работа, меняющая форму.
Та же работа, два места для ИИ
ИИ сбоку vs. ИИ в центре
ИИ сидит в соседней вкладке. Поток, роли и ревью остаются прежними. Каждый выкручивается сам, на свой лад.
+10–20% прибавки по краю. Узкое место остаётся там же.Поток, роли и ревью перестроены так, чтобы строил именно ИИ. Общий контекст, он не умирает в одном разговоре.
Другой порядок прироста. Не на 10% больше, а сама работа меняется.Когда это до меня дошло, вопрос перестал быть «какой инструмент мы внедряем» и стал «что в нашем способе работы было спроектировано для мира без ИИ». Тогда я и посмотрел внутрь.
Диагноз: каждый выкручивается сам
Где-то в конце марта, ещё до того, как мы перешли на Claude, я сел с людьми из продукта, дизайна и инженерии Prolog и задал простой вопрос: как ты используешь ИИ изо дня в день? Что хорошо, где застревает, какое узкое место ты видишь в операциях.
То, что я услышал, меня зацепило.
Каждый пользовался своим инструментом. Один в Copilot, другой в Claude, третий сваливал всё во внутренний ИИ Prolog. И хуже разрозненного инструмента был разрозненный контекст: то, что человек выстраивал в разговоре с ИИ, умирало прямо там, вместе с ним. Команда поддержки, например, собрала хороший материал внутри ИИ Prolog, с правилами того продукта. Только вот это не доходило до команды по шинам, которой нужен был тот же тип контекста и которая начинала с нуля.
Одна засела у меня в голове. Devs избегали использовать ИИ для review большого PR из страха сжечь кредиты до конца недели. Подумай об абсурде: человеку приходилось выбирать между тем, чтобы закончить с ИИ собственную задачу, которую он обязался сдать, или потратить тот же кредит на review гигантского PR коллеги. Это превратилось в конкуренцию за дефицитный ресурс. И тогда никто не хочет браться за чужой review.
Кто-то из команды свёл это к фразе, которую я больше не смог выкинуть из головы:
Мы производим с ИИ, а проверяем без ИИ.
Каждый выкручивается сам, по-своему, с тем инструментом, что подвернулся. То, что работало у одного, не становилось рецептом для другого. Не было стандарта, не было общего места.
И дело было не только в способе, а в структуре
Чем больше я смотрел, тем яснее становилось, что это не решить, просто научив всех «пользоваться лучше». Способ использования был симптомом. Не готова была структура под низом. Обнаружились три дыры.
Во-первых, контекст жил разбросанным. Кусок в Notion, другой в Drive, ещё один в Jira, в Figma, в Fathom. Не было единого источника истины. Поэтому каждый новый разговор с ИИ начинался с объяснения всего с нуля, потому что нужная ему информация лежала в пяти местах и не была собрана ни в одном. Мы платили токенами, запросами и временем просто за то, чтобы заново собрать контекст, который уже где-то существовал.
Во-вторых, человек был клеем. Кто-то из продукта генерирует spec с ИИ, кладёт в doc, отправляет ссылку следующему, который берёт это и закидывает в свой ИИ-проект. ИИ появлялся на концах, никогда в середине: он производил кусок, человек нёс результат руками до следующего инструмента, и другой ИИ начинал заново. Поток оставался человеческим.
В-третьих, архитектура. База, которую мы строили десять лет, была сделана для мира, где узким местом был человек, а не ИИ. Местами она запутана и есть куски без тестов, и именно это тормозит быстрые изменения, которые ИИ позволил бы делать. Это ничья моральная вина. Это накопление десяти лет решений, которые работали до сих пор. ИИ просто выставил это напоказ.
И важно сказать: это не изъян команды и не изъян Prolog. Это то, что происходит в любой компании, которая наклеила ИИ поверх старого способа работы. Любая компания с десятилетней историей несёт в себе способ делать, который работал до сих пор. ИИ направляет на него прожектор. И ответственность это изменить моя.
Почему перестраивать всё, а не только инженерию
Первый соблазн, это решить в инженерии. Логично, это там ИИ прижился быстрее всего и там мы уже начали. Но именно там и кроется ловушка.
Если одна область движется на скорости ИИ, а соседняя остаётся на человеческой скорости, я ничего не ускорил. Я лишь переставил узкое место.
Подумай о всём потоке целиком. Если инженерия начинает выдавать за часы, но продукт всё ещё тратит недели на спецификацию, теперь очередь держит продукт. Решил продукт и инженерию, но валидация всё ещё вручную? Застряло на валидации. И это не только в tech: если мы выкатываем много всего, а маркетинг не успевает анонсировать в том же ритме, узкое место ушло в маркетинг. Ускорить один участок не разбирает пробку. Оно лишь толкает её к следующему.
Ускорить участок не значит разгрузить очередь
Узкое место просто переезжает
Я ускорил только инженерию
Я ускорил продукт и инженерию
Каждый участок, который ты ускоряешь, поджигает следующий. Пробка не рассасывается; она переезжает.
Поэтому в конце апреля мы начали перестраивать весь tech. Продукт, дизайн, данные, качество. Не только инженерию. Если ИИ идёт в центр, он идёт в центр всего потока, а не одного куска.
Что впереди
В следующих статьях я раскрою каждую часть этого. Что такое «harness», инфраструктура, благодаря которой ИИ выдаёт результат по-настоящему, а не просто отдаёт разрозненные куски. Как меняется работа каждой должности, когда строит уже ИИ, а человек становится тем, кто направляет и проверяет. И почему верный вопрос, когда что-то ломается, перестал быть «что мне теперь делать» и стал «чего не хватило в контексте, чтобы это не повторилось».
Трансформация идёт, с попаданиями и с промахами. Расскажу о том и о другом здесь, по мере того как это происходит. Это не рецепт. Это то, что мы проживаем. Если пригодится как карта тому, кто тоже строит, тем лучше.