Технический директор Duetto
Каждое утро специальный агент выгружает для меня список решений, ожидающих моего рассмотрения. Он проводит меня по ним, а я утверждаю их, редактирую или запрашиваю дополнительную информацию. Никаких встреч, никакой подготовки, никаких презентаций.
Это стало возможным благодаря APEX, что расшифровывается как Agentic Product Execution (агентное создание продуктов). В этой системе хранится всё, что нужно любому сотруднику Duetto для создания продукта: что мы создаем, зачем, кто это делает, а также находится ли функция на этапе разработки или всё еще вызывает споры.
«Это возникло потому, что информация о продуктах в Duetto когда-то была разбросана там же, где и в большинстве софтверных компаний: в репозиториях кода, JIRA, Confluence, Slack, электронной почте. Вся эта работа была реальной, но никак не связанной между собой. APEX — это активный репозиторий, куда продуктовая и инженерная команды вносят данные и который объединяет то, что хранится в других системах».
Я говорю вам об этом, потому что с проблемой такой разобщенности сталкиваются не только разработчики ПО. Любой бизнес — отель в той же степени, что и наша компания, — функционирует на основе знаний, которые хранятся в головах людей, в папках «Входящие», в инструментах, которые не общаются друг с другом. И любому бизнесу нужен способ, с помощью которого сотрудники, выполняющие работу, могли бы находить эти знания, действовать на их основе и поддерживать их в актуальном состоянии. То, что мы создали для решения этой проблемы в Duetto, полезно любому, кто сталкивается с точно такой же трудностью.
Как работает APEX.
Каждый документ представляет собой файл в обычном текстовом формате (markdown) с машиночитаемыми метками вверху (владелец, статус, тип, дата), а его расположение указывает на то, какой команде он принадлежит. Изменения поступают в виде предложений и проверяются так же, как инженеры проверяют код. Для тех, кто хочет погрузиться в детали, мы описали техническую сторону работы APEX здесь: apex.duetto.ai.
Что это изменило для нас.
«Никаких догадок. Раньше идея рождалась в виде документа на одной странице, проходила через встречи и согласования и превращалась в испорченный телефон. Теперь же любое изменение в APEX содержит информацию о том, кто и когда его внес, поэтому никто не переписывает прошлогодние обоснования под результаты текущего квартала».
Корпус (собрание файлов внутри APEX) проиндексирован как для машин, так и для людей: семантический поиск, поиск по ключевым словам и граф взаимосвязей между документами. Наше средство автоматического рецензирования кода считывает изменения, а затем обращается к APEX, чтобы проверить, соответствует ли их замысел целям продукта.
Часть дисциплины обеспечивается программным обеспечением, а не людьми. Спецификация не может быть утверждена без подтвержденного результатами эксперимента, приложенного к делу. Инициатива не может перейти в стадию реализации без назначенного топ-менеджера в качестве спонсора — конкретного живого человека.
Откуда взялся APEX.
В мою первую неделю в Duetto проходила выездная встреча в Далласе, где руководство продуктового и инженерного направлений обсуждало будущее разработки. Бесконечные совещания, огромные документы и полное отсутствие возможности что-либо отследить были моей главной болью на предыдущей работе в должности технического директора TripAdvisor. Использование git-репозитория (с контролем исходного кода) для всех знаний по продуктам и разработке — старая идея, которая терпела крах снова и снова, потому что для работы в нем не-инженеров требовал специальный инструментарий, а раньше такой инструментарий стоил дорого. Больше это не так. Вот что изменилось на самом деле.
Я представил идею APEX в Далласе 29 января. Первый коммит был сделан 7 февраля под названием, которое никто бы не стал размещать на слайде: llm-supported-pdp-sdlc. Позже в том же месяце на выездном мероприятии по выходу на рынок в Канкуне наш директор по продукту (CPO) Картик, одна из вице-президентов по продукту Сабрина и я потратили три часа на доработку концепции. Я записал обсуждение, расшифровал дома и превратил в требования. В марте я написал браузерное приложение, в апреле в него вошли все остальные, а в июне мы окончательно перенесли туда всю информацию из Confluence.
Является ли APEX новой концепцией?
По частям APEX практически не содержит ничего принципиально нового. Хранение документов вместе с кодом, фиксация решений в письменном виде и предварительное рецензирование предложений до их реализации — устоявшиеся практики. APEX объединяет эти практики и делает знания доступными как для людей, так и для агентов.
Мы хотели объединить знания о продуктах и разработке в одном репозитории, создать общий рабочий процесс рецензирования, браузерный интерфейс для не-инженеров и агентов, которые могут предлагать изменения в рамках этого процесса. Я сделал один выбор для компании, которая уже живет в git, и эта ставка еще не сыграла окончательно.
Как не-инженеры используют APEX.
Инженеры работают в привычных для себя инструментах. У всех остальных есть две «двери». Любой сотрудник Duetto может зайти в APEX Companion и прочитать хранящиеся там сведения о продукте и разработке. Прозрачность — часть моей философии, и я предпочитаю, чтобы люди видели то же, что и я. Вторая «дверь» — это ассистент в Slack и корпоративном Claude.ai.
По состоянию на 25 августа в APEX насчитывалось около 3255 документов, причем примерно две трети из них — это мигрированная библиотека Confluence. Остальное, включая 194 инициативы, было создано непосредственно в APEX и работает по модели рецензирования.
Как это выглядело бы для отеля.
Меня часто спрашивают, как всё это помогает отельерам. Понимание того, как работает компания и кто за что отвечает, важно для отеля точно так же, как и для софтверной компании. Представьте себе ночного менеджера, которому нужно переселить гостя: он должен иметь возможность найти утвержденную процедуру, узнать, кто может одобрить расходы и когда в последний раз обновлялись эти инструкции, и всё это — не разыскивая кого-то, кто уже ушел со смены.
Я не призываю никого строить свой собственный APEX, хотя это проще, чем кажется. Я выступаю за создание корпоративной базы знаний: документов, проиндексированных для удобства поиска, с видимыми связями между ними. Вместо того чтобы заставлять сотрудников разыскивать информацию повсюду, вы говорите: вот где хранится информация, которая приводит наш бизнес в движение. Кто отвечает за укомплектованность штата горничных, кто отвечает за поставки, кто за выставление счетов, кто наши поставщики.
«Вам не обязательно писать код. Начните с уже используемых инструментов для работы с документами, четкого распределения ответственности, уровней доступа под каждую роль и поиска, который помогает людям находить актуальные инструкции».
Я воспринимаю этот тип базы знаний как световой меч джедая: инструмент, который вы подстраиваете под конкретные задачи. Вам не обязательно писать программное обеспечение самостоятельно, но вы должны взять на себя ответственность за то, как знания организованы, проверяются и поддерживаются в актуальном состоянии.
Четыре вещи, о которых стоит помнить при создании агентной системы знаний.
Управление (Governance)
Привязывайте процесс проверки к степени возможных последствий, а не к типу документа. Сначала мы сделали наоборот и перестроили всё вокруг того, какой ущерб может нанести ошибочное изменение. Рутинные изменения отправляются на автоматическую проверку.
Ответственность (Ownership)
Привяжите систему к уже существующей организационной структуре, поскольку технологии работают лучше всего тогда, когда они моделируют человеческие процессы, а не наоборот. Наши продуктовые команды структурированы по автономным группам (подам), поэтому именно эту модель мы использовали для разграничения ответственности. Назначение ответственного — это лишь начало: чтобы база знаний приносила пользу, нужно регулярно пересматривать документы, делать даты проверок видимыми и отправлять устаревшие инструкции в архив. История изменений говорит о том, что произошло, но она не говорит, актуален ли документ в данный момент.
Интеграция систем (Connecting systems)
Репозиторий заслуживает доверия только тогда, когда он заменяет что-то старое, а не просто увеличивает общую кучу. Мы заморозили Confluence вместо того, чтобы запускать его параллельно с APEX, потому что две системы, претендующие на роль источника правды, означают, что никто не доверяет ни одной из них.
Защитные механизмы (Guardrails)
Это имеет такое же значение, как и контент. ИИ галлюцинирует и будет продолжать галлюцинировать. Используйте проверки, которые не зависят от того, насколько модель считает собственную работу правильной. Автоматизированные проверки навязывают явные правила; тесты проверяют ожидаемое поведение; ревью выясняет, соответствует ли изменение задуманному. Наше автоматизированное код-ревью возвращается к APEX, чтобы проверить изменение на соответствие спецификации. Люди по-прежнему несут ответственность за одобрение важных изменений.
Вот где я провел бы черту: ИИ и поиск должны заниматься поиском нужной информации, потому что это наконец-то стало получаться хорошо. С чем их не стоит путать, так это с исправлением того, как коллеги работают друг с другом — эти отношения никогда не были той проблемой, которую ИИ должен был решать. Хорошие коллеги по-прежнему залог хорошего бизнеса.
APEX не принимает решения за нас. Он сохраняет обоснование в письменном виде, где его может найти любой (человек или агент), чтобы мы могли вернуться к решению, не восстанавливая всю дискуссию заново. В этом и заключается главная ставка: создать репозиторий достаточно хорошо, чтобы люди перестали спрашивать друг друга, где находится правда, и начали спрашивать об этом напрямую. Инструменты для решения этой проблемы сейчас дешевы так, как это было невозможно еще несколько лет назад. Больше нет ни одной уважительной причины вести бизнес на основе знаний, которые никто не может найти.