Anthropic публично пишет: к маю 2026 больше 80% кода, который они вливают в свой production codebase, авторствовал Claude (When AI builds itself). Это их цифра и их методология атрибуции — не проверенный факт из вашей организации. Как рыночный сигнал она всё равно заслуживает внимания: лицензии Claude Code наверняка стоят и у вас, а AI там до сих пор используют как умный автокомплит — дописать строчку, сгенерировать тест, ускорить рутину.
Разрыв не в бюджете на подписки. Он в том, что происходит вокруг инструмента после того, как деньги на него потрачены. Дело не в цифре Anthropic самой по себе. Она работает как индикатор: там, где эта цифра реальна, ей предшествовала организационная работа, которую большинство компаний с теми же лицензиями попросту пропустили. Закупка ключей и подписок — это ещё не enablement. Без подготовки под AI-формат инструмент остаётся ровно тем, чем его сделала команда, — автокомплитом с хорошей репутацией.
Почему воркшоп «что такое RAG» ничего не решает
Пока подготовки нет, у команды нет ответа на три простых вопроса. Какие задачи действительно стоит отдавать AI, а какие — нет. Как ревьюить то, что он вернул, если раньше ревьюили только человеческий код. Как встроить эту петлю проверки в обычный SDLC так, чтобы через два-три месяца качество вывода не начало тихо ползти вниз.
Каждый нерешённый вопрос — это цена, которую компания платит уже сейчас: часы инженеров на разбор непонятного AI-кода, риск пропустить регресс, который раньше ловил человек-ревьюер, и ощущение, что дорогой инструмент почему-то не даёт обещанного ускорения. Воркшоп «что такое RAG» эту цену не снижает. Демка в зуме — тоже: она показывает, что AI умеет, но не меняет ничего в том, как команда с ним работает завтра на реальной задаче.
Три вещи, которые должны быть готовы до старта
Чтобы AI можно было встраивать осмысленно, а не точечно, нужно закрыть три условия одновременно.
Процессы декомпозированы под AI-формат — задача разбита так, что понятно, какой её кусок отдать агенту, а какой оставить человеку. Данные доступны и разложены так, чтобы агент мог их прочитать и с ними работать, а не упирался в закрытые форматы и ручной экспорт. И точки ревью определены заранее, до того как агент что-то произвёл, — а не придуманы постфактум, когда вывод уже лежит в пул-реквесте и его надо срочно как-то оценить.
Последний пункт — не мелочь для галочки. Определить точку ревью заранее — значит заранее решить, что именно проверяется и по какому критерию, вместо того чтобы открывать diff и вычитывать его построчно, надеясь поймать проблему глазами. Это ровно тот разрыв, который держит инженеров в театре ревью вместо инженерной работы над критериями: чтение AI-кода строчка за строчкой выглядит как труд, но не заменяет заранее сформулированный критерий приёмки.
Декомпозиция под AI-формат — это конкретное разделение по типу риска: агенту — участки с проверяемым результатом (миграция схемы данных, генерация тестов по уже описанным AC, рефакторинг по фиксированному паттерну), человеку — участки, где цена ошибки высока, а критерий приёмки нельзя формализовать заранее (архитектурные развилки, интеграции с внешними системами без явного контракта). Без этого разделения получается то же, что происходит сейчас в большинстве компаний с уже купленными лицензиями: агенту дают всё подряд, а потом вручную вычитывают весь вывод, потому что заранее не решили, какому куску можно доверять по умолчанию.
Без этой тройки AI буквально нечем и негде работать в масштабе — какой бы мощной ни была модель за лицензией.
Где enablement перестаёт быть теорией
Разрыв закрывается практикой, которая начинает жить внутри обычного delivery-флоу, а не отдельным тренингом. Реальные задачи из бэклога компании становятся учебным материалом вместо синтетических примеров. Playbooks по ревью AI-вывода лежат в том же PR-флоу, что и весь остальной код — до отдельной wiki-страницы, которую открывают один раз и забывают, дело обычно не доходит. Evals подвешены к релизам. И у практики есть owner: конкретный человек с полномочиями и KPI на качество AI-вывода. Размытая коллективная ответственность такого уровня конкретности не даёт.
Вот как это выглядит в enterprise-контуре на практике: работа идёт с настоящими артефактами, которые остаются в продакшене после того, как сессия закончилась. Разговорный SQL-бот к data lake. ML-модель next best offer. Прокси-микросервис георезолвинга и трекер таймстампов, написанные через AI-assisted coding прямо в ходе учебной сессии с командой, — десятки сессий по 100–200 человек, где на выходе не слайды, а код в проде.
Разница с обычным корпоративным обучением здесь не в формате подачи, а в предмете. Обычный тренинг учит концепции на синтетическом примере, который забывается через неделю, потому что его негде применить. Здесь учебная сессия сама производит production-артефакт: участники выходят не с сертификатом о прохождении курса, а с работающим сервисом, который на следующий день эксплуатирует их же собственная команда. Это меняет мотивацию усваивать материал — ошибка в упражнении не абстрактна, она видна в проде через день.
Механика ревью: три слоя вместо одного финального клика
Ревью AI-вывода в этом контуре устроено не как одна финальная проверка «вроде норм», а как три слоя, каждый со своим критерием и своим моментом в цикле релиза.
Layer 1 — Regression. Фиксированный набор reference-кейсов с известным ожидаемым выводом: edge-кейсы прошлых инцидентов, кейсы из демо, которыми фичу одобряли (их тоже прогоняют, но не только их), минимум один adversarial-вход на тип вывода — prompt injection, пустой, malformed. Любой новый фейл блокирует релиз. Ключевое поле в описании такого кейса — origin: он должен указывать на реальный инцидент, а не на пример из презентации.
id: rag-stale-corpus
origin: incident-2026-03
input:
query: "действующая ставка по тарифу X"
expected:
must_contain:
- "актуальный документ"
must_not_contain:
- "archived"
pass_criteria:
- no_archived_docs
- answer_groundedLayer 2 — Distribution check. Для RAG и классификаторов — 20–50 свежих реальных входов через новую версию, сравнение не с «идеалом», а diff против снапшота прошлого релиза: распределение длины и формата ответа, изменение retrieved-чанков, сдвиг confidence к краям. Сдвиг к краям — модель либо уверена во всём, либо ни в чём — это и есть сигнал хрупкости, а не шум.
Layer 3 — Human spot-check. Обязателен перед первым проддеплоем нового вида вывода: доменный человек читает 10–20 реальных выводов с конкретными вопросами — нет ли данных, к которым модель не должна иметь доступ; счёл бы эксперт это корректным; нет ли adversarial-эксплуатации, которую автотест не заметит.
Owner. Один человек подписывает sign-off по всем трём слоям. Если перед релизом нельзя назвать конкретного человека, который отвечает за это решение, — это уже первый сигнал риска, а не деталь для потом. Отсутствие названного владельца и превращает «выглядело ок в staging» в привычку делегировать ответственность в никуда.
Механика и рабочий harness под первые два слоя разобраны отдельно — в материале про eval как release-критерий против demo-grade, там же лежит и минимальный harness с явными пороговыми значениями drift.
Ловушка demo-grade eval
На бумаге три слоя выглядят как достаточная страховка. Но здесь и живёт главная ловушка — demo-grade eval: фичу одобряют на тех же входных данных, на которых её же и питчили инвестору или заказчику. Тесты проходят, демо блестит, а в проде на реальном разнообразии запросов модель ведёт себя иначе — и никто не может назвать точку, где это должны были поймать.
Три конкретных failure mode, которые чаще всего дают этот разрыв на практике: RAG корректно отвечает на курированном корпусе стейджинга и галлюцинирует на полном корпусе со stale-записями; классификатор деградирует после смены входной схемы upstream и никого не оповещает; AI-сгенерированный код проходит все автотесты, но вносит security-паттерн, который эти тесты никогда не покрывали. Три разных стека — один и тот же корень: eval-датасет совпал с демо-датасетом.
Есть ещё два системных провала, которые к demo-grade не относятся напрямую, но живут рядом с ним. Первый — pass-критерии формулируют после прогона, глядя на то, что получилось, а не до него: «выглядит разумно» вместо заранее зафиксированного порога. Второй — снапшот, к которому сравнивают distribution diff, обновляют без объявления в момент деградации, вместо того чтобы разобраться в причине сдвига; тогда плохое поведение молча становится новой нормой, а diff на следующем релизе его уже не поймает.
Что отличает enablement от демо
Самое неожиданное здесь — не технология и не методика ревью, а то, что реально остаётся в памяти команды. Механику работы с AI люди усваивают в тот момент, когда после учебной сессии в проде остаётся рабочий код, который реально идёт в релиз, а не на лекции или красивой демонстрации. Разница между настоящим enablement и его имитацией измеряется одним вопросом: что происходит с созданным кодом после того, как сессия закончилась — он уезжает в продакшен или растворяется вместе со слайдами.
Тот же вопрос стоит и на уровне всего SDLC, не только момента ревью: если декомпозиция, доступ к данным и ревью встроены в обычный delivery-флоу с первого дня — AI покрывает весь цикл, а не только написание кода, от clarify-диалога с заказчиком до мониторинга в проде. Эта встроенность и отличает enablement от разовой демонстрации возможностей модели.
Почему это работает именно в enterprise
У крупной организации есть вполне рациональный страх: сломать процессы, которые и так работают, ради инструмента, который ещё не доказал предсказуемость. Ключевой запрос здесь — не «внедрить AI побыстрее», а получить предсказуемую поставку AI-ценности внутри существующих governance-ограничений, не рискуя тем, что уже стабильно приносит результат. Enablement, встроенный в реальный delivery-флоу с owner, playbooks и evals на релизах, отвечает на этот запрос: он не обещает революцию за одну сессию, но и не заставляет выбирать между скоростью AI и контролем, который enterprise не готов отдать.
Репозиторий с минимальным harness под первые два слоя: github.com/dobryakov/eval-harness.
Если у вас уже куплены лицензии Claude Code, а production-выхлоп всё ещё на уровне интересных демо — дело не в инструменте и не в модели за подпиской, а в практике, которая должна была появиться вокруг него ещё до того, как первый агент тронул реальный код.