AI-внедрение: решает протокол, а не модель

Первый вопрос — от компании, где уже есть AI-политика, золотой стандарт инструментов, платформа поверх LLM-провайдеров и закупленные лицензии, но в систему это не складывается: одну задачу решают то на восемь, то на сорок тысяч строк, команды тянут Shadow AI и локальные модели, а споры идут за токены и доступы. Сорок тысяч строк ошарашивают Алексея объёмом, и он вспоминает мем про агента, который поменял триста файлов, написал тысячу тестов, и ничего не запустилось. Причина, по его опыту, чаще не в модели, а в протоколе вокруг задачи: как она сформулирована на входе и что считается выходом каждого этапа. Отсюда стандартизация — обязательный формат задачи в трекере, фильтры и фоновые агенты, не пропускающие дальше размытую постановку, — и сегментация: кто автокомплитит, а кто делегирует задачу целиком. Прорастает это через локальных гуру: пока они не купили практику сами, политика остаётся страницей в вики.

Shadow AI Алексей предлагает читать как диагностический сигнал: понять, что именно тащат и почему, и по возможности легализовать. Его пример: компания закупила Claude, а людям с большим объёмом фактчекинга субъективно удобнее был Codex; по исследованиям Codex лучше следует инструкциям, Claude чаще выдумывает, и, по субъективным ощущениям Алексея, на Opus 5 это всё ещё так. Реальное применение он предлагает наблюдать по pull request — вплоть до агента, который раз в час собирает аналитику и складывает в бэклог непротиворечивые предложения; такому агенту нужны фильтрация чувствительных данных и доступ на чтение и запись. Александр добавляет взгляд из большой компании: сверху вы энейблите бюджеты, лимиты токенов, доступы и модельный шлюз, но пройти уровни зрелости за команды нельзя. Кто-то дошёл до spec-driven development, кто-то запускает рой агентов, и чужой опыт не переносится — работают демо-дни и живые примеры соседей.

Второй вопрос адресован Александру: стоит ли завести requirement ledger — бухгалтерскую книгу требований — и мерить, сколько принятых ограничений агент потерял или переоткрыл. Александр признаётся, что раньше об этом не думал: сильные модели с хорошим harness и так держатся структуры MD-файлов, проверяют себя и в конце предлагают опции там, где на старте не договорились. А в закрытом контуре с моделями послабее требования теряются заметно, и там леджер исходных, уточнённых, реализованных и проверенных пунктов может окупиться — с оговоркой, что через одно-два поколения моделей его выкинут как оверинжиниринг. Алексей сомневается в ценности: такой реестр смешивает функциональные требования, нефункциональные и ADR, и непонятно, как его мерить. Он вспоминает идею event sourcing действий агента, о которой слышал год назад, но реализаций не видел, и сводит задачу к фитнес-функциям и независимому ревьюеру — фоновому агенту, который проверяет согласованность по pull request или раз в N смерженных изменений.

Третий вопрос — как посчитать и защитить эффект AI перед CIO или CEO. Алексей считает его запоздалым: сверху сначала приходит «нам нужно ускорение в десять раз», и лишь со счётом за кредиты выясняется, что ускорения нет, а багов больше. В аудитах он часто видит примерно на сорок процентов больше возвратов из QA и более долгие исправления: разработчик не знает, как фича вообще была сделана. Померить организацию целиком почти нереально, команду и продукт — можно: lead time, time to market и пять DORA-метрик вместе с rework rate, недавно добавленной пятой. Александр вспоминает метафору колбасной фабрики и доклад лида платформенной команды Авито на IT-Пикнике: считать они умели throughput, а бизнесу продали перевёрнутый «эффективный cycle time» — задача едет условно на 15–20 % быстрее. Но среднее скрывает распределение, а сэкономленное время само по себе не экономия: пока оно не перешло в другую полезную работу или в меньшую стоимость поддержки, до P&L оно не доходит.

Четвёртый вопрос — от стаф-инженера: как продать AI-native операционную модель на уровень CEO. Ответ Алексея зависит от компании: нецифровому бизнесу вроде условного Walmart хватит поддерживающих ассистентов и чат-ботов; вертикальному GenAI-продукту скорость нужна, чтобы не быть съеденным провайдерами и конкурентами; а сытый лидер рынка ответит «конечно, мы AI-native», покажет сто двадцать пять рабочих групп и утопит идею в подкомитетах — срочности у него нет, как у Kodak не было нужды в цифровой камере. Александр вспоминает внедрение юридического AI в объединении, которому сто двадцать лет, где на тему выделяют полчаса в неделю. Пятый вопрос — из чата технических директоров: чем отличаются OpenSpec и GitHub Spec Kit? Попробовать стоит оба, переносить текущие проекты Алексей не стал бы. В Spec Kit единица работы — фича, ведомая микроводопадом от constitution и specify до тасков и имплементации; с дельтами и сильной связанностью он работает плохо. OpenSpec заточен под существующую базу, идёт циклом explore, propose и apply и легко правится файлами в проекте.

Выбор между инструментами Алексей сводит к даче: если в руках только лопата, газон от неё лучше не станет — десять методологий в его книге нужны как карта выбора. Александр добавляет: прогнать методологию на пет-проекте дешевле, чем знать о ней понаслышке. Отдельная беда, по Алексею, в том, что LLM не показывает, чего ты не знаешь, и даёт ощущение, что всё работает. Последний вопрос — про порядок evals в greenfield: Александр собирал бы систему по ходу первой бизнес-фичи — каркас архитектуры, CI/CD, контурные тесты, линтеры, фитнес-функции, — а evals ставил бы поверх детерминированных метрик, сам читая отчёты, а не запуская автономный луп. Цена автономии без границ — фоновый агент Алексея, который «починил» сломанную рассылку на его сайте, переключив feature flag с единицы на ноль; пропажу писем он заметил через две недели. Сам Александр пускает агента в production только через GitOps: конфигурация в репозитории, Argo CD или Flux с проверками. Три сессии закрыли девятнадцать вопросов, а завтра ведущих ждёт первый выпуск нового подкаста втроём — с Женей Сергеевым.