Как разработчики и AI-агенты могут делиться обучением в Shopify River

Когда агент что-то делает, вся компания должна учиться на этом, чтобы у каждого разработчика был доступ к общим инсайтам и удачным решениям.

До того как Тоби Лютке возглавил Shopify, он учился программированию через систему ученичества в Германии — по сути, так, как люди веками осваивали ремесло: в общей мастерской, наблюдая за теми, кто уже умеет работать. Позже, описывая River от Shopify, он использовал близкое слово: Lehrwerkstatt — учебную мастерскую, где «весь цех является классом».

X обсуждает впечатляющие цифры вокруг River, Slack-native AI agent от Shopify. Всего 5 938 сотрудников Shopify работали с River в 4 450 разных Slack-каналах, а теперь River пишет совместно примерно каждую восьмую объединённую pull request в компании. Это важно, но куда важнее понять, почему это работает.

River умеет читать код, запускать тесты, открывать pull request, запрашивать data warehouse, анализировать production traces и иногда спорить с планом, если считает его плохим. Отлично. У многих компаний скоро появятся умные coding agents. У некоторых они уже есть.

Но интереснее всего то, что River работает не в одиночку, а там, где его видят все.

Ставка на мастерскую

Я уже утверждал, что agents лучше работают с явным, последовательным и хорошо документированным софтом. Им нравятся «скучные» вещи: схемы, тесты, соглашения, понятные инструкции по запуску и кодовые базы, где не нужно проводить глубокий ретроспективный разбор с тем единственным инженером, который помнит, почему build script приходится запускать дважды. Если запустить agent в запущенный repo, он по сути превращается в эффективный аудит инженерной дисциплины. Agents отражают наши инженерные практики.

И здесь Shopify выглядит очень хорошо. Без всей предварительной инженерной работы River не стал бы успехом. В начале 2024 года компания говорит, что у неё было много репозиториев, особые среды разработки и медленные feedback loops. Затем она приняла два непопулярных, но критически важных решения: перевела всё в monorepo под названием World и построила dev environments, continuous integration и production images на Nix как на единый воспроизводимый substrate.

В Shopify поняли, что «код всё чаще будет писаться с помощью AI, и наша инфраструктура должна стать для этого substrate». Но компания пошла дальше, чем просто требовать читаемого кода: она начала создавать общую память об этом коде внутри всей компании.

Коллективное кодирование

У River есть одно ограничение дизайна, на которое должен обратить внимание каждый enterprise architect: он работает только в публичных Slack-каналах. Никаких direct messages. Никаких private groups. Вы вызываете River там, где другие люди могут смотреть, подключаться, искать и учиться. Это звучит как мелкая продуктовая деталь, но это не так. Это операционная модель, почти как open sourcing процесса разработки кода внутри Slack.

Из-за этого каждое взаимодействие с River превращается в видимый transcript. Shopify затем может анализировать эти transcripts, находить повторяющиеся паттерны и возвращать их обратно в skills, prompts и defaults River. Исправление, найденное одним инженером в два часа дня, становится стартовой точкой для следующего инженера в четыре. Модели не нужно переобучаться, чтобы компания становилась умнее, и разработчикам не нужно специально писать документацию. Работа просто должна оставлять след.

Это и есть Lehrwerkstatt в продуктовой форме. Все могут наблюдать, как agent работает.

А теперь сравните это с тем, как большинство компаний внедряют AI. Один разработчик работает с приватным chatbot в приватном IDE в приватном окне, которое никто больше не увидит. Умножьте это на несколько тысяч. Каждый находит свой хитрый способ проверить flaky test, объяснить неудобную границу сервиса или обойти ловушку миграции. Потом сессия закрывается, и открытие умирает. Да, разработчик может работать быстрее, но компания от этого не становится сильнее, чем была вчера.

Транскрипт и есть артефакт

Одна из ошибок в knowledge management, которую совершают компании, — считать, что документацию пишут после работы. Обычно это не работает. Мало кто из сотрудников, разработчиков или нет, хочет тратить время на занудное описание того, что он уже сделал. Разве что за это платят.

River предлагает более удачный паттерн: сама работа создаёт документацию.

Конечно, не каждый transcript полезен. Скорее всего, большинство — нет. Но полезные могут превращаться в skills, defaults, примеры, runbooks, инструкции по repo или ссылки, которые помогают следующему человеку не начинать с нуля. Shopify говорит, что сессии River можно искать и воспроизводить, а найденные в них паттерны компания возвращает обратно в skills, prompts и defaults River. Это не chatbot; это learning loop.

Здесь привычная рамка «AI сделает разработчиков продуктивнее» кажется слишком узкой. Более интересное утверждение в том, что AI может сделать software organizations более обучаемыми. Но само по себе это не произойдёт. Shop floor нужно институционализировать, иначе компания останется атомизированным набором productivity silos.

Магический файл памяти

Здесь полезен agents.md, но только если им правильно пользоваться. agents.md называет себя README для agents и говорит, что его уже используют более 60 000 open source projects. Как разработчику с ним работать? GitHub, опираясь на анализ более чем 2 500 repositories, даёт ясные рекомендации: размещайте команды в начале, будьте конкретны, приводите реальные примеры и задавайте явные границы.

Иными словами, записывайте то, что действительно важно.

Но не путайте файл со способностью. Исследователи ETH Zurich недавно проверили, действительно ли repository-level context files помогают coding agents, и обнаружили, что они часто снижают успешность задач, одновременно увеличивая inference cost более чем на 20%. InfoQ суммировал их вывод так: LLM-generated context files часто вредят, а human-written файлы должны фокусироваться на невыводимых деталях — например, на custom tools, необычных build commands и очень специфических ограничениях проекта.

Вот где возникает enterprise opportunity.

У публичных GitHub-проектов часто не так много невыводимых доменных знаний, которые нужно кодировать, а enterprise software переполнено ими: странные особенности вроде того, почему pricing service нельзя вызывать во время checkout в определённом регионе, или какой legacy API выглядит мёртвым, но по-прежнему обслуживает крупного клиента, или почему data model говорит одно, а revenue recognition — другое. И так далее.

Вот какой контекст действительно стоит сохранять, а не карты каталогов, которые agent может обнаружить сам, или общие предпочтения в кодинге. Именно так выглядит shop-floor версия agents.md: не статичный файл, который кто-то сгенерировал и забыл, а осадок наблюдаемой работы. Agents ошибаются, люди исправляют, возникают паттерны, и только устойчивые уроки становятся инструкциями.

Вы не Shopify

Если всё это звучит здорово, так и есть, — но есть и предупреждение: скорее всего, вы не сможете скопировать Shopify так же, как не стоило бы копировать Google. Вы не Shopify. Большинству компаний не нужно в понедельник объявлять миграцию на monorepo, переход на Nix и запуск Slack-only agent только потому, что River звучит круто. Для Shopify это сработало, но это не значит, что сработает у вас.

Полезнее задавать другие вопросы: где в вашей компании происходит работа с agent и кто из неё учится? Если ответы — «в частном порядке» и «никто», у вас проблемы. Я не говорю, что каждая agent-сессия должна быть в публичном канале. Нельзя выгружать customer data, security incidents, HR issues или privileged production context в корпоративную AI-кофейню. Границы по-прежнему важны. В некоторых случаях они важнее, потому что agents могут двигаться быстрее и затрагивать больше систем, чем люди, как я уже предупреждал.

Но принцип сохраняется несмотря на оговорки: работу agent нужно делать inspectable, reusable и, где уместно, improvable. Организация должна видеть путь от вопроса к вызову инструмента, от неудачной попытки к исправлению, от pull request к повторно используемому знанию.

Общее обучение — это новый старый путь

Годами developer experience в основном означал снижение трения для отдельных людей: быстрее запуск, лучше документация, удобнее APIs и так далее. Всё это по-прежнему важно. Но agentic development добавляет новое требование: shared learning.

Хороший developer experience теперь должен отвечать и на другие вопросы: сможет ли следующий разработчик извлечь пользу из последней agent-сессии? Может ли agent объяснить не только то, что он изменил, но и чему научился? Можно ли превратить частный прорыв в актив команды, не создавая при этом nightmare surveillance? И нет, видимость — это не surveillance, а цель не в том, чтобы оценивать каждый keystroke или превращать разработчиков в производителей контента для корпоративной memory machine. Цель в том, чтобы сделать ценную работу достаточно наблюдаемой, чтобы она накапливалась.

Это в той же мере управленческая задача, что и задача инструментов. Разработчики будут использовать agents, потому что agents помогают им делать работу. Сейчас вы вряд ли смогли бы заставить их остановиться. Но они не станут добровольно производить красивую организационную память как побочный эффект, если workflow не сделает это естественным. Нужно сделать shared shop floor золотым путём, как я применяю это разными способами уже много лет.

В истории River люди по-прежнему остаются учителями. Организация по-прежнему отвечает за то, что считать хорошей работой. Системе по-прежнему нужны judgment, taste, security, cost control и review. Магия возникает тогда, когда вся эта работа происходит открыто, и организация может учиться на обучении.

Вот и есть настоящее обещание agentic coding внутри компаний. Не в том, что у каждого разработчика будет свой private genius, а в том, что каждый разработчик сможет подключаться к collective genius. Лютке учился ремеслу в комнате, где craft был видим, а apprentices учились, наблюдая за работой. Компании, которые победят в эпоху agents, воссоздадут эту комнату для software.

Короче говоря, самое умное, что может сделать ваш AI, — не писать код быстрее. А работать публично.

Материал — перевод статьи с английского.

Оригинал: When software developers and AI agents share the learning