Когда у компании или госорганизации копится большой слой старых систем, главный риск обычно не в одном громком инциденте, а в тысячах тихих уязвимостей, которые годами живут в коде, инфраструктуре и процессах выкладки. Именно на этот слой нацелился новый кейс Anthropic: правительство Альберты показало, как Claude Code помог проверить сотни миллионов строк кода, найти слабые места и ускорить исправления.
Что произошло в Альберте
6 июля Anthropic опубликовала кейс правительства Альберты: команда министерства технологий использовала Claude Code с моделями Opus и Sonnet, чтобы проверить государственные системы на уязвимости и ускорить модернизацию старого кода.
Масштаб выглядит показательно:
- проверено 466 миллионов строк кода;
- сканирование заняло около 20 часов;
- контур охватил 27 министерств, 1280 приложений и 3400 репозиториев;
- в параллельном режиме работали около 50 агентных проверок;
- каждое приложение проверяли примерно по 95 контрольным пунктам безопасности.
Смысл новости не в красивой цифре сам по себе. Важно другое: ИИ использовали не как витринного помощника, а как рабочий слой над большим парком старых систем, где нужно быстро найти проблему, показать конкретный файл и строку, предложить исправление, а иногда сначала дописать тесты, а уже потом менять код.
Почему это важно для бизнеса
У большинства компаний проблема выглядит мягче, чем у правительства, но логика та же самая. Есть старые сервисы, внутренние кабинеты, интеграции, куски самописной автоматизации, забытые репозитории и инфраструктурные настройки, которые никто давно не проверял системно.
В результате бизнес живёт сразу с несколькими видами риска:
- уязвимости копятся быстрее, чем команда успевает их разбирать;
- технический долг мешает выкатывать изменения без страха;
- часть систем слишком старая, чтобы быстро понять, как она вообще устроена;
- безопасность зависит от памяти отдельных инженеров, а не от повторяемого процесса.
Поэтому главный практический вывод из кейса Альберты — ИИ уже может быть не только генератором кода, но и ускорителем проверки безопасности, инвентаризации, переписывания устаревших узлов и подготовки безопасных исправлений под контролем команды.
Практическая ценность такого подхода особенно заметна во внутренних инструментах и интеграциях: речь идёт не о внедрении абстрактного ИИ, а о рабочем слое над реальными системами, где важны проверяемость, скорость и контроль.
Как был устроен подход
По описанию Anthropic, процесс был не магическим, а довольно приземлённым.
- Сначала — массовый обзор. Система проходила по репозиториям, отмечала известные паттерны риска и поднимала кандидатов на проверку.
- Потом — разбор находок. Claude не просто говорил, что «здесь может быть проблема», а ссылался на конкретные файлы и строки, чтобы инженер мог быстро проверить вывод.
- Дальше — исправление. Если узел был понятным, Claude Code мог предложить патч, собрать его и прогнать проверку. Если тестов не хватало, сначала появлялись тесты.
- Если код слишком старый — модернизация. В отдельных случаях старые куски логичнее не латать бесконечно, а переносить в более поддерживаемую форму.
- Наконец — постоянный цикл. Отдельные сценарии атакующей и защитной проверки продолжают проверять системы по мере разработки, а не раз в несколько лет.
Это и есть зрелый сценарий: ИИ не заменяет инженера, а помогает команде быстрее проходить путь от обнаружения проблемы до внятного решения. Именно такой подход с обязательной проверкой человеком обычно и даёт наибольшую пользу.
Где такой сценарий окупается
Не каждой компании нужен аудит сотен миллионов строк кода. Но сам паттерн легко переносится в более земные бизнес-задачи.
- Устаревшие внутренние системы. Старый CRM-модуль, кабинет партнёра, самописная внутренняя операционная система или сервис заявок можно быстро разобрать на слабые места перед доработками.
- Интеграции между сервисами. Там, где данные ходят между сайтом, CRM, почтой, ERP и таблицами, ошибки в правах, логировании и обработке входящих событий часто важнее «красивого ИИ».
- Подготовка к переписыванию продукта. Перед тем как строить новый контур или делать MVP и внутренний продукт, полезно быстро понять, что из старого кода можно сохранить, а что безопаснее заменить.
- Постоянный внутренний контроль. ИИ-агенты можно использовать как повторяемый слой проверки изменений в коде перед слиянием, конфигураций, инфраструктурных шаблонов и документации.
Если говорить проще, бизнес начинает выигрывать там, где безопасность становится не отдельным проектом «когда-нибудь потом», а частью ежедневного цикла изменений.
Ограничения и риски
Из этого кейса не стоит делать вывод, что теперь можно просто дать модели доступ ко всему контуру и ждать чудес. Такой подход работает только при жёстких рамках.
- Нужны правила доступа и понятные границы того, что агент вообще может читать и менять.
- Нужна проверка человеком перед выкладкой исправлений.
- Нужны тесты, иначе быстрый патч легко превращается в быстрый регресс.
- Нужен список приоритетов: сначала самые критичные системы, а не попытка разом «оцифровать всё».
- Нужно помнить, что ИИ хорошо ускоряет обзор и подготовку решений, но не отменяет архитектурного мышления и ответственности команды.
Именно поэтому сильный сценарий начинается не с полного автопилота, а с ограниченного рабочего участка, где можно видеть результат и проверять качество.
С чего начать без большой перестройки
Для большинства компаний первый полезный шаг выглядит так:
- выбрать один старый сервис, репозиторий или связку интеграций, где уже страшно вносить изменения;
- собрать короткий обзор с помощью ИИ: уязвимости, слабые места, устаревшие зависимости, дыры в документации и тестах;
- отделить быстрые исправления от участков, которые лучше перепроектировать;
- встроить повторяемую проверку в обычный цикл разработки.
Такой старт лучше, чем абстрактная программа «внедрения ИИ в безопасность». Он даёт видимый результат, не ломает текущую работу и помогает понять, где ИИ действительно снижает риск, а где только создаёт лишний шум.
Если у команды уже накопились старые внутренние сервисы, ручные интеграции и опасные участки кода, то логичнее сначала собрать один понятный контур проверки и исправления, а уже потом расширять его до полноценного ИИ-слоя для разработки и сопровождения.
FAQ
Это история только для больших госорганизаций?
Нет. Масштаб проекта в Альберте экстремальный, но сам подход хорошо переносится на компании с несколькими старыми сервисами, внутренними кабинетами, CRM-интеграциями и накопленным техническим долгом.
Заменяет ли ИИ команду безопасности или разработчиков?
Нет. Практическая польза возникает тогда, когда ИИ ускоряет поиск, объяснение и подготовку исправлений, а человек принимает решение, проверяет выводы и контролирует выкладку.
С чего начать, если код старый и документации почти нет?
Начать стоит с одного критичного участка: получить карту репозитория, список рисков, пробелы в тестах и документации, а затем выбрать несколько исправлений с самым понятным эффектом.
Где здесь бизнес-выгода, кроме безопасности?
Она в том, что команда быстрее понимает старые системы, реже боится изменений, тратит меньше времени на ручной аудит и проще переводит поддержку устаревшего кода в управляемый процесс.
Кейс Альберты показывает простой сдвиг: ИИ становится полезным не тогда, когда красиво отвечает в чате, а тогда, когда помогает команде пройти длинный путь от старого небезопасного кода к более понятной и проверяемой системе.
Обсудить статью со своим ИИ-ассистентом
Скопируйте эту статью в Markdown: заголовок, ссылка и вся структура текста уже будут готовы для Cursor, Claude, ChatGPT или любого другого агента.
Готово для вставки в ИИ-ассистент.