Платформенные программы, управление AI и решения, которые за ними стоят. В каждом кейсе: в чём было ограничение, что я решил и что из этого вышло.
К началу 2023 года инструменты GenAI быстро распространялись по Medidata без централизованного контроля. У инженерных команд не было стандартизированного доступа к ИИ-инструментам разработки. У бизнес-функций (Marketing, Sales, PMO) не было регламентированного пути внедрения GenAI в рабочие процессы. Подразделения сами отправляли заявки на оценку пересекающихся продуктов, и объём запросов перегрузил то, что InfoSec и Legal успевали рассмотреть. Процесс приёма заявок, запущенный в январе 2023 года, встал уже через несколько месяцев.
Первый вопрос был таким: кому давать доступ в первую очередь. Исследование Harvard Business Review показало, что senior-разработчики получают от AI-автодополнения кода заметно больше пользы, чем junior-разработчики: они достаточно хорошо понимают код, чтобы оценить и поправить то, что предложил инструмент. Опираясь на эти данные, я убедил руководство выбрать top-down стратегию внедрения вместо случайной выборки или добровольной opt-in модели.
Мы попросили каждого engineering-менеджера в 10 командах номинировать самых сильных инженеров. Так сформировалась когорта примерно из 50 senior-разработчиков. Критерии успеха были сфокусированы на плотности дефектов и динамике code churn, то есть на том, сохраняет ли код с ИИ-поддержкой стандарты качества, а не только на уровне внедрения или объеме выходных артефактов.
Пилот подтвердил гипотезу. Когда результаты представили руководству, сначала предложили продолжить поэтапное расширение доступа на месяцы вперед. Я возразил: пилот уже валидировал инструмент, а растянутый поэтапный запуск для 1 000+ инженеров создаст больше операционной нагрузки, чем снизит риск. Такой запуск означал бы несколько уровней доступа, постоянные жалобы от инженеров в очереди и задержку продуктивных эффектов, которые пилот уже показал. Руководство согласовало полный запуск.
Роллаут Copilot закрыл инженерные команды и только их. Marketing, Sales, Product и другие нетехнические команды сами находили GenAI-инструменты и подавали бизнес-кейсы в процесс приёма, который к тому моменту уже стоял.
Вместо того чтобы по одной рассматривать каждую заявку на новый инструмент, я сменил стратегию: стандартизировать Google Gemini как корпоративную GenAI-платформу и научить сотрудников решать задачи уже доступными средствами. Я создал общекорпоративный Gemini Gem для стандартизированной фиксации заметок встреч и провел практическое обучение NotebookLM для 150 нетехнических сотрудников. Во многих отправленных бизнес-кейсах ответом было не «утвердить новый инструмент», а «вот как сделать это тем, что уже есть». Полный роллаут Copilot плюс работа по Gemini и NotebookLM: сейчас управляемой программой пользуются 1 200+ человек в инженерных и бизнес-командах.
К началу 2025 года было понятно, что чинить надо структурно. Я помог создать AI Operating Committee (AIOC), который заменил ad-hoc обработку заявок на управляемый контур принятия решений.
Наибольший эффект дали два изменения в политике. Первое: мы ограничили круг сотрудников, которые могут подавать бизнес-кейсы. Раньше заявку на инструмент мог отправить любой сотрудник, из-за чего комитет получал поток запросов от людей, которые просто увидели рекламу или услышали о продукте. В новой модели подавать заявки могли только руководители подразделений, что добавило уровень бизнес-обоснования до попадания заявки в комитет. Второе: мы перенесли ответственность за бюджет. Раньше R&D закрывал стоимость инструментов, запрошенных другими департаментами. По новой политике любой инструмент оплачивался из бюджета запрашивающего департамента. Это обеспечило реальную поддержку со стороны руководителей: если команда не готова финансировать инструмент, потребность недостаточно подтверждена.
В комитет входили SVP и VP из разных функций, которые могли напрямую отчитываться перед executive committee по одобренным инструментам. Мгновенный результат: были выявлены и устранены 12 дублирующих бизнес-кейсов. Marketing и Sales независимо подали кейсы на разные продукты, решающие одну и ту же задачу. Аналогично было у PMO и R&D. В ряде случаев мы просто назначали человека, который показывал запрашивающей команде, как закрыть потребность с помощью Gemini, без покупки нового инструмента.
Платформы баз данных достигают окончания поддержки по заранее известному графику, и когда это происходит, вендор (AWS для MySQL, Microsoft для SQL Server) начинает взимать плату за расширенную поддержку с каждого инстанса, всё ещё работающего на старой версии. Размер платы растёт вместе с парком. В крупной регулируемой среде парк большой, поэтому каждый такой срок приходит как известный заранее многомиллионный штраф за бездействие.
За четыре года я последовательно вёл три такие миграции. Ни одна не была технически экзотической. Сложность была в том, чтобы заставить большое число людей приоритизировать изменение, которое не приносит новых функций, к сроку, установленному кем-то другим. Вместе эти программы предотвратили около $30M, и каждая давала урок, ускорявший следующую. Самый ценный урок был вообще не про базы данных, а про то, кто платит.
Первая программа несла штраф в $6M, если бы мы не успели уйти с MySQL 5.7 до отсечки AWS. Сам апгрейд был рутинным. Сложность была в другом: убедить десятки инженерных команд поставить его в приоритет. Поэтому я использовал стандартный сценарий: встречи со стейкхолдерами, рассылки по программе и регулярный обход инженерных лидов с напоминанием, что их инстансы должны двигаться.
Это работало, но держалось целиком на моём давлении, и темп упирался в то, скольких лидов один человек реально может обойти за неделю.
Через год пришёл следующий срок, MySQL 8.0 → 8.4, на этот раз с более крупным штрафом в $8M. Мы начали с того же сценария, но на полпути я поменял то, что действительно имело значение: не план коммуникаций, а модель учёта затрат.
До этого штраф висел как расходы на уровне всего R&D, что по сути означает, что он не принадлежал никому. Поэтому я привязал каждый инстанс базы данных к продуктовому направлению, которое им владеет (внутри мы зовём это «experience»), и к отвечающему за него SVP и перенёс затраты на уровень отдельного направления вместо общего котла R&D. Как только SVP увидел свою строку в бюджете и стал владельцем штрафа, который сгенерируют его немигрированные инстансы, приоритизацию больше не нужно было создавать вручную. SVP вели её сами. Моя роль сместилась с давления на инженеров на поддержание честности «табло». Это «табло», собранное вручную для одной программы, сейчас встраивается в постоянную систему, Unified Ops Portal, описанный ниже.
Последняя программа была самой крупной, штраф $13M. Microsoft SQL Server подходил к окончанию поддержки, и мы платили бы за расширенную поддержку с каждого оставшегося инстанса. Мы начали в ноябре 2024 года и первый месяц ничего не мигрировали, только выясняли, насколько всё плохо. Всё было плохо.
Корень проблемы был в легаси-ПО, которое мы лицензировали и хостили в собственном дата-центре. Клиенты покупали лицензию, и у нас не было механизма принудить их к обновлению, поэтому в эксплуатации было около 30 разных версий продукта, каждая из которых могла быть привязана к версии БД, которую мы пытались вывести. Регулируемая отрасль усугубляла дело: каждую поддерживаемую комбинацию нужно было формально валидировать, и эту валидацию мы проводили одновременно с валидацией новых релизов.
Это вынудило принять два решения до того, как кто-либо коснётся сервера. Какие версии мы вообще поддерживаем? Мы выбрали пять последних. И на каком юридическом основании мы снимаем клиентов с остальных? Мы ввели политику, обязывающую их обновиться до последней версии. Когда объём и политика были зафиксированы, остальное стало оркестрацией между командами, которые обычно не двигаются синхронно:
Чтобы удержать качество на стольких передачах, я построил шаблоны, которым команда DBA следовала шаг за шагом. Это самая дешёвая страховка от того, что уставший инженер начнёт импровизировать в неподходящий момент. Воркшопы со стейкхолдерами и привычный инструментарий управления изменениями держали функции согласованными. Мы модернизировали 98,5% всех затронутых URL и серверов. Оставшиеся 1,5% застряли по-настоящему, это не лёгкие случаи, которые бросили недоделанными.
Инструменты накапливаются. За достаточное число лет инженерная организация строит систему, чтобы отслеживать одно, дашборд, чтобы следить за другим, таблицу, на которую кто-то молится ради третьего, и каждый из них по отдельности разумен. Цена проявляется позже, когда ответ на действительно простой вопрос (какие серверы работают на ОС с окончанием поддержки, сколько на самом деле тратит эта команда, куда движется утилизация) означает вход в пять систем и сведение их вручную. Я ощутил это напрямую. Программы модернизации БД и FedRAMP обе начинались с недель сборки картины из инструментов, которые не разговаривали друг с другом.
Unified Ops Portal решает это: одна система и одно представление вместо обхода разрозненных. Это внутренняя платформа для разработчиков в сегодняшнем стандартном смысле: единая входная дверь к операционным данным и инструментам, нужным инженеру или руководителю, а не каталог ссылок на системы, которые их хранят.
Это была продуктовая, а не программная работа, и я вёл её именно так. Началось с исследования. Я изучил внутренние платформы, построенные компаниями, которые умеют это делать, прежде всего Spotify Backstage, а также внутренний инструментарий Airbnb и другие, чтобы понять, что хорошая платформа на самом деле делает и, что не менее важно, какой объём их обычно топит. На основе этого я составил продуктовую дорожную карту и определил объём: чем портал владеет, с чем он лишь интегрируется и в каком порядке появляются возможности.
Дисциплина здесь сводится к умению говорить «нет». Внутренняя платформа почти всегда проваливается одинаково: пытаясь быть всем, она становится худшей версией инструментов, которые должна была объединить. Поэтому дорожная карта в той же мере говорит, чего портал намеренно не делает, как и то, что он делает. Правильно провести эту границу было самой трудной и самой ценной частью продуктовой работы.
Объём теперь определён и в значительной мере построен. Портал отслеживает:
Сейчас в разработке финансовый компонент: отнести затраты обратно на команды и продуктовые направления («experience»), которые их порождают. Это не случайность. Ручное «табло» затрат по направлениям, заставившее миграцию MySQL 8.4 приоритизировать саму себя, работало, но было собрано вручную для одной программы и затем отложено. Финансовый слой превращает это разовое «табло» в постоянную функцию, и это в миниатюре весь смысл портала: взять то, что менеджер программы каждый раз пересобирает с нуля, и сделать так, чтобы оно стояло само.
FedRAMP Moderate задаёт планку, которую облачная система должна взять, прежде чем сможет обрабатывать федеральные данные США, и он построен на базовом наборе NIST 800-53 Moderate, насчитывающем несколько сотен контролей. Разрыв между тем, чтобы действительно работать безопасно, и тем, чтобы доказать каждый из этих контролей стороннему аудитору, велик, и большая часть работы живёт именно в этом разрыве. Я вёл программу, которая его закрыла, то есть превращал длинный список «пока не соответствует» в именованные находки, ответственных владельцев, сроки и доказательства, которые аудитор действительно примет.
Работа началась с оценки разрывов относительно базового набора Moderate. Вместе с командой безопасности я сопоставил текущее состояние платформы с каждым требуемым контролем и отделил те, что мы уже выполняли, от тех, что нет. Эта оценка дала артефакт, на котором держалась вся остальная программа: Plan of Action and Milestones, POA&M: постоянный реестр каждой открытой находки, её владельца, шага ремедиации и срока. В FedRAMP POA&M это не бумага, которую собирают в конце, а инструмент, из которого ведут программу.
Но прежде чем этому можно было доверять, нужно было определить, что вообще входит в объём. Инвентаризация вендоров установила, что реально находится внутри границы авторизации, а модель владения закрепила конкретное имя за каждой областью контролей, чтобы ни одна находка не провалилась тихо в зазор между двумя командами. Когда граница и владельцы были определены, остальное стало управлением программой довольно классической формы, но с необычно неумолимым сроком (календарём аудитора). Я вёл регулярный цикл ремедиации по POA&M, удерживал владельцев в их сроках и разбирался с зависимостями, которые тормозят такую работу.
Именно на зависимостях менеджер программы и отрабатывает свой хлеб. Многие находки нельзя было закрыть, пока другая команда не сделает своё. Например, пункты по неподдерживаемым ОС ждали, пока серверная команда обеспечит замену оборудования, то же ограничение по срокам поставки, что формировало программу модернизации БД. И ремедиация была лишь половиной каждого пункта. Вторая половина: собрать доказательства, потому что в аудите FedRAMP контроль, который нельзя доказать, всё равно что отсутствует. Для каждой закрытой находки я следил, чтобы существовал артефакт, её подтверждающий, а не только сама работа.
Сами находки охватывали пять областей:
Объявление Atlassian о завершении жизненного цикла Jira Server вынудило перейти на Jira Data Center. Сама миграция была рутинной, сложным было окружение вокруг неё. Jira была в Medidata источником истины для комплаенса, а состояние платформы отражало годы неконтролируемого роста. API-политики не было: пользователи могли создавать собственные API-ключи без контроля. Изменения запрашивались ad-hoc, без формального процесса оценки и приоритизации платформенных изменений.
Момент, который зафиксировал проблему: автоматизированный скрипт одного пользователя отправлял 10 000 API-запросов в минуту одновременно в оба узла Jira и остановил весь инстанс для организации. Не было ни политики, чтобы это предотвратить, ни механизма управления, чтобы поймать риск до сбоя.
Я предложил рассматривать Jira не как инструмент, который «просто работает» или нет, а как платформенный продукт с определенным владельцем, сервисными стандартами и управлением. Это было не только про терминологию, последствия были практическими. Jira-администраторы получили чувство владения платформой вместо роли постоянных пожарных. Пользователи получили понятный уровень сервиса, включая SLA по времени ответа на Jira-тикеты, чего раньше не существовало. А организация получила контур управления для оценки изменений до их внедрения.
Я создал руководящий комитет из трех представителей PMO, по одному от R&D, Service Delivery и Product (это три подразделения с самой высокой нагрузкой на Jira), двух Jira Admins и меня. Комитет регулярно встречался, чтобы рассматривать и приоритизировать платформенные изменения, запросы на API-доступ и предложения по интеграциям.
API-политика стала самым спорным изменением. После инцидента с 10 000 запросов в минуту мы ввели правило: все API-запросы проходят ревью руководящим комитетом до выдачи ключей. Это намеренно добавило трение; прежний подход «ключ может создать любой» почти уронил прод.
Проект занял около 4 месяцев от старта до завершения, включая проверки комплаенса и юридический аудит, чтобы подтвердить соответствие Data Center регуляторным требованиям Medidata. Фактическая миграция прошла в запланированное 8-часовое окно простоя с вечера пятницы до утра субботы. Мы сознательно оставили self-hosted Data Center вместо перехода в Atlassian Cloud, из-за требований комплаенса и ограничений по размещению данных того времени. (Переход в Cloud начался позже и идёт сейчас, он есть ниже, в разделе «Ещё кейсы».)
Сама миграция прошла без инцидентов: нулевая потеря данных, откат не потребовался. Работа по управлению, сделанная в предыдущие месяцы, привела к тому, что среда после миграции была чище и лучше управляемой, чем исходная.
Symbridge строила платформу криптокастоди и обмена, для которой требовалась сертификация SOC1 и SOC2. Предпосылкой для сертификации было внедрение контроля доступа к клиентским данным и административным функциям платформы. Эта задача стала центром конфликта между Operations и Security и угрожала сорвать весь график сертификации.
Operations выступала за индивидуальные права доступа. Их модель: каждый получает персональный набор прав под текущие задачи, а Operations управляет тем, кому что выдается. Такой подход был максимально гибким: когда появлялись edge cases, а в стартапе биржи они появлялись постоянно, команда могла сразу выдать точечный доступ без ожидания смены роли.
Security настаивала на строгом Role-Based Access Control. Их модель: права назначаются ролям, каждому пользователю выдается не более двух ролей, а доступ регулируется принципом Least Privilege. Этот подход ставил в приоритет аудитопригодность: SOC-аудиторам нужна структурированная модель доступа, а не таблица с исключениями по каждому человеку.
Напряжение было реальным. Operations воспринимала RBAC как ограничение, которое замедлит работу при нестандартных ситуациях. Security считала персональные права аудиторным кошмаром, который может сорвать сертификацию.
После риск-анализа требований обеих команд я рекомендовал иерархический RBAC на основе модели NIST. Security рассматривала и отклонила ABAC (Attribute-Based Access Control) и PBAC (Policy-Based Access Control), поскольку для компании на стадии стартапа они давали слишком высокую стоимость внедрения и сопровождения. Иерархический RBAC дал структурированную и аудитопригодную модель, нужную Security, и одновременно сохранил достаточную гибкость наследования ролей для опасений Operations по нестандартным сценариям.
Я представил рекомендацию CEO с прямой ссылкой на работу NIST по RBAC, обозначив как преимущества по безопасности, так и практические минусы предпочтительного для Operations подхода, а именно то, что индивидуальные права заметно усложнят и удорожат поддержание SOC-сертификации. Поддержка NIST добавила рекомендации вес, которого не было бы у внутреннего мнения без внешней опоры.
Рекомендацию утвердили и внедрили за следующие 4 месяца, что завершилось успешной сертификацией SOC1 и SOC2. Уязвимости админ-панели снизились на 30%. Важно, что нестандартные сценарии, из-за которых переживала Operations (случаи, где иерархического RBAC якобы не хватит по гибкости), за время моей работы в Symbridge не проявились. Опасения были понятными в теории, но не совпали с реальным операционным паттерном после запуска системы.
Apple Intelligence предлагает Writing Tools (проверку текста, переписывание, резюмирование). Русского среди поддерживаемых языков нет, и Apple не говорит, когда и изменится ли это. Для примерно 260 миллионов русскоязычных пользователей встроенный помощник по письму, который есть у носителей английского, французского и ещё десятка языков, попросту недоступен. Эта пустота и стала отправной точкой Грамоты. Цель была конкретной: принести инструменты письма в стиле Apple на русский язык, полностью на устройстве, без передачи данных куда-либо.
Первая ставка была очевидной: взять сильную готовую русскоязычную модель и поставить её на устройство как есть. YandexGPT-5-Lite-8B, модель от Яндекса с открытым кодом, 8 миллиардов параметров, контекстное окно 32k. На MLX, на Mac с M1 Pro, всё работало нормально. А вот прогнать её через CoreML для реального iOS оказалось совсем другой историей. После квантизации до Q4 она едва тянула на iPad и вообще не запускалась на iPhone, а сам путь конвертации ломался, потому что YandexGPT собран не по стандартному Hugging Face Transformers, и обычный инструментарий не понимал структуру.
Настоящая проблема была не в размере, а в поведении платформы: iOS и iPadOS управляют памятью для локальных процессов куда агрессивнее, чем macOS, аллокатор так и не выгружал модель чисто, и ОС убивала процесс независимо от того, сколько в устройстве оперативки. Ограничивало не железо, а то, что операционная система готова держать в памяти. Модель осталась legacy-веткой только для Mac.
Дальше был RuAdapt Qwen-3B, русскоязычная адаптация Qwen2.5-3B со своим токенизатором. Меньше YandexGPT, но недостаточно обучена для исправления грамматики без серьёзных дополнительных вложений, а доводить её до нужного уровня было заведомо проигрышным делом. Здесь же стало понятно, какого реального масштаба задача: гонять модель на 8 или 3 миллиарда параметров ради опечатки в сообщении примерно как ехать на самосвале за парой досок в Leroy Merlin. Технически может, для задачи дико избыточна. Отбросили.
Третья попытка пошла в сторону меньшего и своего: модель, обученную с нуля на русском, сразу в ANE-native раскладке по рекомендациям Apple, на теории, что она выучит, как выглядит правильный русский. Выучила, до определённого предела, но не тот регистр. Корпус был формальный и академический. Никому, кто пишет другу или правит предложение, не нужен академически точный русский. Нужно, чтобы поправили их живой, современный русский, а не подняли его до стиля, которым никто не говорит.
При 82 миллионах параметров она была быстрой, но с реальным потолком. На собственной оценке давала GLEU около 0,77 и справлялась примерно с 40% из 23 категорий ошибок, что звучит терпимо, пока не посмотришь на пропуски. Она заваливала целые классы ошибок, среди них согласование и спряжение, и придумывала редкие словоформы, для которых у неё просто не было места. Быстро и уверенно неправильно это не продукт. Модель отправилась в мусорку.
Более трудным решением было перестать строить с нуля и поставить на чужую предобученную модель. FRED-T5-large от ai-forever, около 820 миллионов параметров. Готовые модели это особый риск: узнаёшь, можно ли довести их до ума, только уже потратив время. В холодном тесте без дообучения FRED дал 0% на задаче исправления. Звучит как приговор, пока не поймёшь почему: FRED это денойзинговая модель, обученная восстанавливать замаскированный текст, а не выполнять инструкции, и её никогда не просили «исправь предложение». Знание правильного русского явно сидело под неправильной учебной целью. Дообучение было ставкой.
Несколько сотен тысяч пар «источник и цель» сгенерировали через YandexGPT для корпуса дообучения, частью локально, частью через API, когда локальная генерация оказалась слишком медленной даже в параллельных процессах. Два бага делали результат намного хуже, чем он был. Первый: каждое исправление выходило удвоенным. Причина мелкая: токенизатор не добавлял токен конца последовательности при обучении, и модель так и не выучила, где остановиться. Починка на уровне пайплайна данных подняла сырой счёт с кажущихся 25% до 67%. Второй баг был в самих данных. Аудит корпуса вскрыл «правильные» цели, которые сами были неграмотными, и нашлись они только когда цели прочитали руками. Обе починили, оценку переориентировали на ошибки, которые реально делают люди (аканье и оканье, путаница «а» и «о» в написании, в первую очередь), и модель дошла до примерно 85% на продуктовом benchmark. Она вышла как первая рабочая версия Грамоты: около 900 МБ, 8 бит, на GPU.
И она была медленной. Около 2,16 секунды на предложение, потому что сгенерировать исправленное предложение значит прогнать весь декодер на каждый выходной токен. Это число и заставило принять следующее решение, а следующая модель этот движок из приложения убрала.
Решением была не уменьшенная версия той же идеи, а совсем другая идея. Вместо того чтобы писать новое предложение, размечать каждое слово (оставить, удалить, поправить падеж, поправить букву) и применять правки обычным детерминированным кодом. Эту форму Apple Neural Engine выполняет нативно, чего генеративный декодер не мог никогда.
Результат: 246 миллионов параметров, 99,7% операций модели на ANE, около 17 миллисекунд на предложение. Примерно в 130 раз быстрее. Такая модель ещё и не умеет перефразировать по построению: её правки берутся из фиксированного меню, и «переписать предложение с нуля» в этом меню нет. Для проверки, чья работа в основном оставлять текст в покое, это правильный размен.
Она выиграла и по качеству. Решающим был очный тест на 212 словах свежего текста, которого не видела ни одна модель. Tagger сделал 13 исправлений, все 13 верные. Старая генеративная модель сделала 21, три из них неправильные, включая одно, которое поменяло смысл предложения. На этом всё и решилось. Генеративный движок на ~900 МБ ушёл из приложения.
Самая ценная починка во всём проекте не тронула модель. Оценочный набор, который вёл обучение, собрали из того же массива данных, на котором модель училась, поэтому его оценки мерили запоминание, а не навык. Одна категория ошибок показывала 22,6% на этой оценке и 4,4% на честно отложенной. Починка была скучной: заморозить benchmark, который никогда не попадает в обучение, и каждый раунд отправлять в карантин свежий срез новых данных, чтобы туда не утекало и недавнее.
Та же дисциплина поймала ещё два бага, о которых никто не подозревал. Расчёт теоретического потолка для архитектуры tagger вскрыл код, который не мог воспроизвести 38,9% ответов, до которых в принципе должен был дотягиваться. А если перемножить вероятности вдоль петли самообучения, той, что должна была подкидывать модели новые целевые примеры каждый раунд, окажется, что она выдавала около 16 из 1 400 примеров, которые полагались, за раунд. Петля выглядела автоматической и была в основном декоративной. Никто не перемножал вероятности до этого. Теперь все три проверки идут автоматически после каждого раунда обучения, потому что до этого две регрессии шли незамеченными 49 раундов, и всё, что за ними следило, это дашборд.
Первое честное число здесь было неприятным: модель исправляла 41% предложений, в которых вообще не было ошибок. Каждый обучающий пример до этого содержал ошибку, поэтому модель выучила, что текст всегда сломан. Теперь примерно треть обучения это пары «чистое к чистому». Если модель должна понимать, когда не делать ничего, этому тоже надо учить.
Всё дальше построено вокруг точности, потому что неправильная правка портит текст, который пропущенная правка просто оставила бы в покое. Словарный слой, ловящий несловарные опечатки, срабатывает только когда сходятся три условия сразу: слова нет в частотном списке на 422 000 форм, предложенная замена совпадает с реальным механизмом опечатки (замена по созвучию или соседняя клавиша), и исправление минимум в 10 раз частотнее ближайшего конкурента. Ложные срабатывания на живом неформальном тексте упали с 16,7% до 0,5%.
Самое неприятное открытие пришло из того, что приложение измерили честно, а не предположили, что с ним всё нормально. На реальном, грязном интернет-русском сегодняшний tagger оставляет полностью правильными 24% предложений; если не трогать текст вовсе, таких 30%. На таком тексте он ломает примерно столько же, сколько чинит.
Маленький обученный судья, который сидит поверх существующего ранжирования и решает, применить верхнюю подсказку или оставить предложение как есть, обходит приложение сразу по всем меркам: найденных исправлений вдвое больше, с 12% до 24%, урона меньше, чистого текста оставлено в покое с 65% до 76%, полностью правильных предложений с 24% до 34%. Обычно одно улучшается за счёт другого; здесь все четыре сдвинулись в нужную сторону вместе. Сам судья это линейная модель, около шести строк арифметики над 42 числами, которые пайплайн и так считает, так что на телефоне он идёт без нагрузки. На момент этой записи это исследовательский результат, ещё не в продукте.
Некоторые ошибки это не неправильная буква и не пропущенное окончание, а слово, изувеченное до неузнаваемости («заче», «чсемьсот»). Ни один tagger не опишет правку для слова, которое он вообще не может разобрать. Это вторая, отдельная дорожка: tagger помечает слово, которое не смог разрешить, маленькая локальная модель Gemma (Gemma 4 E2B) переписывает только этот кусок, и в исходное предложение вставляется обратно лишь помеченный фрагмент.
Эта дорожка теперь вшита в приложение, а не сидит в исследованиях. Swift-порт воспроизводит эталонный замер на Python байт в байт, а урезание словаря модели до того, что реально нужно русскому, ужало бандл с 6,0 ГБ до 2,8 ГБ. Она идёт отдельной загрузкой, а не в комплекте с приложением, потому что не всем она нужна каждый день. Эта же модель ещё и чисто конвертируется в новый runtime Apple, Core AI, с численно идентичным выходом. Это отложено как опция для скорости под следующую ОС, а не как улучшение качества: слова, которые она всё ещё не берёт, это предел самой модели, и сменой runtime его не сдвинуть.
Проверка бесплатная, а Тьютор это платная часть. Он превращает твои же исправленные предложения в упражнения, разнесённые во времени, чтобы ты отрабатывал именно те ошибки, которые реально делаешь, а не общий план урока. Он собран и проверен: 1 120 из 1 120 сгенерированных упражнений сходятся с корректором. Осталось там принять продуктовые решения, а не инженерные.
На Mac, где есть запас по памяти и питанию, которого нет у телефона, у Грамоты появился ещё и полноценный редактор с ghost-text подсказками, теми самыми, что принимаешь клавишей Tab. То же правило приватности, то же условие офлайна, класс функций, который сборка для телефона просто не потянет.
В начале проекта инстинкт подсказывал, что для запуска модели на Neural Engine нужна переработка архитектуры. Вместо этого вопрос проверили напрямую, примитивным зондом, до всякой переработки. Вывод: механизмы внимания, хоть einsum, хоть matmul, хоть собственный fused attention от Apple, на ANE не выполняются никогда, а авторегрессивный декодер, который генерирует по одному токену, работает при длине последовательности единица, и это привязано к CPU по построению. Честный вывод на тот момент был такой: модели, что были на руках, не той формы для ANE, и чтобы туда попасть, нужна другая архитектура. Это отложили до следующей модели, а не стали продавливать.
Tagger и есть та другая форма: один проход классификации на предложение вместо одного шага декодера на токен, ближе к encoder-архитектурам, которые Apple использует в своих transformer-моделях под ANE. Двухминутный зонд стоил почти ничего и не дал уйти в переработку, которая всё равно провалилась бы; те 99,7% это тот же вопрос, отвеченный позже, уже на модели, форма которой железу подошла.
Скучная часть выпуска была, как всегда, той самой, что реально блокировала релиз. Обновление до беты iOS сломало сборку, и в итоге дело оказалось в повреждённом локальном состоянии Xcode, а починилось чистым клонированием. Баг с чёрным экраном шёл от градиентного фона, перекрытого навигационным контейнером, который на iOS рендерится непрозрачным, а на macOS его просто нет, и лечился привязкой фона к scroll view. Пустая иконка потребовала переустановки с очисткой кэша на живом устройстве. Архив для TestFlight падал, потому что всю неделю сборка компилировала одну архитектуру, а архив компилирует две, и один тип (Float16) на Intel-маках просто не существует, так что Mac-приложение теперь только под arm64, и это нормально, потому что его главная фича на Intel всё равно не работает. Ни одна из этих проблем не интересна. Каждая останавливает релиз, если её не найти.
Грамота сегодня работает на tagger: 246M параметров, 99,7% на Neural Engine, около 17 миллисекунд на предложение, в App Store для iPhone, iPad и Mac, версия 1.3. Дорожка Gemma для слов, которые tagger не разбирает, вшита и доступна отдельной загрузкой. Судья, решающий, применять ли правку вообще, собран и измерен, но ещё не в продукте. Тьютор собран и проверен. Следующая модель возвращается к тому же подходу с маленькой моделью, но со всем накопленным опытом с самого начала, и оценивается по ошибкам реальной аудитории продукта, а не по абстрактной метрике.
Грамота уже в App Store, а на gramota.troegubov.co есть страница проекта: что приложение умеет и как оно устроено. Осталось главное: сделать его удобнее. Это намного лучшая проблема, чем нерабочая модель.
Инструменты: Claude Opus 4.6, Claude Sonnet 4.6, Grok Code 4.1 Fast, OpenAI Codex, YandexGPT 5 Pro, Xcode (с интеграциями ChatGPT 5, OpenAI Codex, Claude Sonnet).
Общие затраты: ~$128 (~11 700 ₽), из кармана: $89 (~8 100 ₽).
Срок от идеи до рабочего приложения: 2 недели.
Всё началось в Великий пост. Я православный христианин, живу в Америке, и захотел начать системно читать Библию. Казалось бы, что проще: зайти на Amazon и купить первую попавшуюся. Но для русскоязычного православного всё не так просто.
Богослужения совершаются на церковнославянском, а он ближе к южнославянским языкам, чем к современному русскому. Болгары были одними из первых славян, принявших христианство, и литургическая традиция несёт их языковой отпечаток по сей день. Русская Синодальная Библия, стандартный текст, впервые вышла в 1887 году. Проблема очевидна: за 140 лет русский язык сильно изменился. Язык Синодального перевода архаичен, и для современного читателя многие места бывают откровенно непонятны.
Идея была простой: приложение с современным переводом рядом с Синодальным текстом, литургический календарь с чтениями дня и экран «Сегодня», который собирает всё воедино.
1. Полное отсутствие опыта программирования. Ещё четыре года назад это была бы непреодолимая преграда. Скачал бы Xcode, покрутил, посмотрел пару видео на YouTube, написал пару строк и бросил.
Но сейчас всё иначе. Это не первая моя попытка разработки с помощью ИИ: за последний год я пробовал несколько идей с Grok и OpenAI. На первый взгляд они справляются неплохо, но делают слишком много допущений. Про Claude я слышал давно и решил: ладно, мне нужна ещё одна подписка.
Claude меня впечатлил. С точки зрения человека без технического бэкграунда это действительно мощный инструмент. Он автоматически учёл главную проблему ещё до того, как я об этом задумался: лицензирование.
2. Лицензирование. Синодальная Библия, которой почти 140 лет, находится в общественном достоянии, а современные переводы нет. Пришлось отказаться от изначальной концепции с двумя переводами, частично из-за лицензий, частично из-за следующей проблемы.
3. Контроль качества. От современного перевода я отказался в первую очередь из-за доверия. Русская Православная Церковь никогда не утверждала современный русский перевод Библии. Есть мнения, что современные переводы можно использовать как справочный материал, но я решил не рисковать. Сократил MVP до одного приложения с каноническим Синодальным текстом, но с хорошей поддержкой для понимания.
25 февраля я открыл Claude и описал концепцию. Через 20 минут был готов React-прототип, который можно было запустить и потрогать. Через 40 минут были готовы все файлы для работы в Xcode.
Следующие дни я провёл в режиме пинг-понга между Claude Chat и Xcode. В какой-то момент решил попробовать Claude Code, агента, подключённого напрямую к проекту через терминал. Это стало переломным моментом.
Моё главное опасение касаемо Claude Code и любого инструмента с MCP было связано с атаками через внедрение промтов. Я минимизировал этот риск, ограничив доступ агента одной папкой с файлами проекта. После настройки работа пошла значительно быстрее.
Контраст с предыдущим опытом ИИ-разработки был разительным:
«Эта функция не работает как описано, можешь исправить?»
«Конечно, проблема в строке 59. Вот исправление.»
Clean build. Новая ошибка.
«Не помогло, и теперь ещё одна ошибка.»
И так до бесконечности.
Способность Claude Code видеть полный контекст проекта изменила всё. Главным ограничителем стал не функционал инструмента, а лимит использования: приходилось ждать сброса.
Встроенные ИИ-интеграции в Xcode, к слову, практически бесполезны. Единственный реальный сценарий это быстрые исправления предупреждений, и даже тогда они часто создают новые проблемы.
К выходным я окончательно отказался от современного перевода. Вместо этого вложил время в создание полноценного толкового словаря: определения архаичных слов Синодального текста, которые затрудняют понимание для современного читателя.
Здесь я начал тратить деньги на API. Большая часть из $10, потраченных на xAI, ушла на попытку извлечь и отформатировать OCR-скан словаря 1890 года. Не лучшая идея: дореформенный русский алфавит содержал буквы, которых давно нет (ять, фита, i десятеричное), и данные оказались хаотичными. Но опыт был интересный.
Потом пришло озарение: все слова, которым нужны определения, уже содержатся в тексте Библии. Нужно просто извлечь уникальные архаизмы и получить для них определения. Для этого я использовал YandexGPT.
Тут, думаю, объяснять не нужно: YandexGPT 5 Pro показал себя отлично для работы с русским языком, что логично. В рамках акции при регистрации мне начислили 4 000 ₽ бесплатного вычислительного ресурса. У меня уже был опыт запуска локальных LLM через Python, так что работа с API не стала чем-то совсем новым. Некомфортно было другое: отправляешь промпт и гадаешь, хватит ли баланса и правильно ли сформулирован запрос. Совет: не включайте автопополнение баланса на API-аккаунтах. Это верный способ проснуться с дырой в бюджете.
У YandexGPT обнаружилась интересная особенность. Поначалу он возвращал: «Извините, я не могу выполнить этот запрос, попробуйте другой». После перенастройки скрипта я пришёл к выводу, что модерация контента срабатывала на некоторые библейские термины: непредвиденный побочный эффект фильтров безопасности при работе с религиозным текстом. При этом определения это фундамент, на котором строится общество. Если мы не можем договориться об определении чего-либо, мы, по определению, не можем двигаться дальше.
После 7 часов обработки словарь должен был быть готов. Не тут-то было. Claude Code при проверке нашёл значительное количество пропущенных определений. Остаток лимита Claude ушёл на заполнение пробелов. Когда лимит заканчивался, я переключался на Codex. Codex лучше, чем GPT и xAI? Да. Лучше, чем Claude? К сожалению, нет.
Ещё раньше, на версии 0.4, я решил заняться производительностью. Приложение тормозило при переключении между страницами, примерно секунда задержки. Для офлайн-приложения это неприемлемо. Codex пытался отладить проблему несколько раз, менял параметры, без результата. Зато Grok 4.1 подсказал, как сгенерировать .trace-файл для профилирования через Instruments.
За 30 минут до сброса лимита я дал Codex еще одну попытку. Он не смог открыть trace-файл, не запросив доступ к папкам, не имеющим отношения к проекту: напоминание о том, почему я изначально ограничил доступ каждого инструмента одной папкой. Подождал 30 минут. Claude проанализировал файл и внёс изменения. Разница была моментальной.
Самая свежая функция дальше всего от чтения Библии: наводишь камеру на икону, и приложение говорит, какой это святой или сюжет, целиком на телефоне, без единого кадра наружу. Сначала работает Core ML-классификатор, обученный на каталожных репродукциях. Если он уверен, он называет икону; если нет, показывает короткий список «возможно, это…» из поиска по тому же каталогу, а не выдаёт один неверный ответ.
Честнее всего там, где всё перестаёт работать. Модель права примерно в 65% случаев на чистых снимках, но фото, снятое в храме, под углом, с широкой стеной вокруг доски, попадает в мёртвую зону: модель всё ещё ставит нужную икону первой, просто недостаточно уверенно, чтобы пройти порог. Поэтому на «не нашлось» приложение не сдаётся: оно предлагает обрезку с уже выделенной доской, и повторный прогон только по доске обычно и вытягивает. На одном контрольном снимке обрезка по доске подняла уверенность в нужном святом с 0,36 до 0,60, за порог. Пороги подобраны на чистой валидации и потребуют перенастройки на реальных фото, это и есть следующая работа здесь.
Две недели и $128 спустя приложение готово и живёт в App Store. С тех пор проект вырос: сейчас это версия 1.4, с молитвословом, церковным календарём и распознаванием икон. Исходники доступны на GitHub, страница проекта: synodal.troegubov.co.
Claude Pro ($20), ChatGPT Pro ($20), Grok ($30), Grok Code API ($10), YandexGPT 5 ($3 + 4 000 ₽ промо), Claude API ($5). Итого: $128. Из кармана: $89.
В 1944 году Управление стратегических служб (предшественник ЦРУ) опубликовало засекреченное полевое руководство для рядовых саботажников, действовавших в нацистской Европе. Цель была простой: научить обычных людей уничтожать вражеские организации изнутри: без взрывчатки, без привлечения внимания и не попадаясь.
Руководство было рассекречено в 2008 году. Читать его сегодня странно, потому что тактики саботажа из разделов 11 и 12 (про организации, менеджеров и сотрудников) неотличимы от обычной дисфункции большинства рабочих мест. Не периодически. Постоянно. Руководство читается как диагностический чек-лист организационного здоровья, написанный людьми, которые понимали, как организации на самом деле разрушаются.
Это наблюдение привело к простому вопросу: если руководство описывает, как разрушить организацию через повседневное поведение, даёт ли разворот каждой инструкции на 180° рабочий набор управленческих принципов? Оказывается, да. И упражнение полезнее, чем кажется, потому что разворот не производит ничего нового: он производит те же принципы, которым следуют компетентные менеджеры. Что добавляет руководство, так это обрамление: оно заставляет признать, что обычное организационное поведение не нейтрально. Оно разрушительно, и тот факт, что никто этого не намерен, не меняет результата.
Раздел открывается инструкциями по принятию решений: «Настаивайте на том, чтобы всё делалось через официальные каналы. Никогда не позволяйте использовать обходные пути для ускорения решений.» «По возможности передавайте все вопросы на рассмотрение комитетов. Старайтесь делать комитеты как можно больше, не менее пяти человек.» «Как можно чаще поднимайте нерелевантные вопросы.» «Возвращайтесь к вопросам, решённым на прошлом заседании, и пытайтесь пересмотреть их целесообразность.»
Мишень тут время. Каждая инструкция создана, чтобы его поглощать, без явных актов разрушения и без очевидного виновника. Инструкция «призывайте к осторожности» особенно эффективна, потому что против неё практически невозможно возразить. Никто не хочет оказаться человеком, отмахнувшимся от законного опасения. Саботажник замедляет всё, выглядя при этом самым ответственным человеком в комнате.
Инструкции для менеджеров-саботажников конкретнее и узнаваемее: «При распределении задач всегда сначала выдавайте незначительные. Важные задачи поручайте неэффективным работникам.» «Настаивайте на идеальном исполнении в относительно неважных продуктах.» «Чтобы снизить моральный дух и производительность, хвалите неэффективных работников, давайте им незаслуженные повышения. Придирайтесь к эффективным сотрудникам.» «Никогда не передавайте свои навыки и опыт новым или менее опытным сотрудникам.» «Умножайте процедуры и согласования. Добивайтесь, чтобы там, где достаточно одного, требовалось три согласования.»
Описанный менеджер не выглядит некомпетентным. Он выглядит старательным, тщательным и даже принципиальным: высокие стандарты, осторожный контроль. При этом он системно разрушителен. Инструкция по распределению задач гарантирует, что критические проекты будут недоукомплектованы, а лучшие люди потратят время на незначительные задачи. Инструкция по продвижению постепенно разрушает нормы производительности.
Инструкции для рядовых сотрудников построены на том же принципе правдоподобного отрицания: «Работайте медленно. Придумывайте способы увеличить количество движений.» «Создавайте как можно больше перерывов в работе.» «Делайте работу плохо и обвиняйте в этом инструменты и оборудование.» «Никогда не передавайте свои навыки новым сотрудникам.» «Запутывайте администрацию любым способом. Заполняйте формы неразборчиво, допускайте ошибки или опускайте требуемую информацию.»
Ни один единичный случай любого из этих поведений не стал бы поводом для увольнения. Каждое объяснимо по отдельности. Умноженные на команду и устойчивые во времени, они разрушительны. Руководство полезно здесь как диагностический, а не дисциплинарный инструмент. Если эти паттерны видны в команде, первый вопрос не «кто виноват», а «какие условия производят это поведение». Медленная работа, постоянные прерывания, жалобы на инструменты иногда действительно намеренный саботаж. Чаще это симптомы плохо спроектированных процессов, слабых инструментов или нечётких ожиданий.
Финальный раздел самый короткий и самый личный: «Давайте длинные и непонятные объяснения на вопросы.» «Притворяйтесь тупым.» «Будьте как можно раздражительнее и сварливее, не доводя дело до неприятностей.» «Распространяйте тревожные слухи, похожие на инсайдерскую информацию.»
Это не сбои процессов. Это межличностные. УСС включил саботаж морального духа, потому что деморализованные организации производят меньше, принимают худшие решения и теряют лучших людей. Инструкция «распускайте слухи» с поразительной точностью описывает то, что происходит внутри организаций, где руководство не общается ясно и часто. Слухи не требуют саботажника. Когда информация скрывается или плохо передаётся, вакуум заполняется сам.
Обращённые принципы не новы. Поручайте важную работу способным людям. Проводите короткие совещания. Нормально обучайте новичков. Общайтесь ясно. Любой управленческий фреймворк охватывает эту территорию.
Что добавляет руководство, так это обрамление. Когда кто-то предлагает добавить ещё один шаг согласования, легко кивнуть. Когда то же предложение распознаётся как тактика из военного руководства по саботажу, вопрос меняется: этот шаг согласования снижает конкретный риск или добавляет задержку, выглядя при этом осторожным?
Упражнение также делает сложнее оправдывать обычное организационное поведение как нейтральное. Оно не нейтрально. Комитет, слишком большой для принятия решений, даёт те же результаты, что намеренное противодействие. Менеджер, терпящий плохую производительность и наказывающий надёжность, производит тот же результат, что и инструкция придираться к эффективным работникам. Различие между намеренным и ненамеренным саботажем важно юридически и морально. Для организации оно не меняет результата.
Самое полезное применение руководства это диагностика. Прочитайте раздел 11 применительно к знакомой вам команде. Отметьте поведение, которое узнаёте: раздутые комитеты, пересмотр решений, цепочки согласований, которые никто не может обосновать, совещания, которые проводятся, потому что они в календаре, неполный онбординг, хорошее отношение к слабым исполнителям, знания, сосредоточенные в одном человеке без плана преемственности. Наличие этих паттернов не означает, что кто-то пытается разрушить организацию, оно означает, что против них никто осознанно не строил. Это состояние по умолчанию, и исправлять его приходится намеренно.