20 февраля Anthropic представила новые функции сервиса Claude. Они связаны с анализом программного кода, в том числе унаследованного. Первые результаты оказались довольно многообещающими, что сразу привело к появлению пессимистических прогнозов. Насколько они обоснованы?
- 1. Введение
- 2. Действительно прорыв или отголоски завышенных ожиданий?
- 3. Когда ждать отечественных аналогов?
- 4. Есть ли место для человека?
- 5. Что изменится в регуляторике?
- 6. Выводы
Введение
20 февраля компания Anthropic представила новые, пока ещё экспериментальные функции своего сервиса Claude. Они заключаются в том, что продукт получил возможность «сканировать кодовые базы на наличие уязвимостей и предлагать точечные программные исправления для проверки человеком».
Практически сразу после этого анонса обвалились акции компаний в сфере кибербезопасности. Бумаги CrowdStrike потеряли 8 %, Cloudflare подешевели на 8,1 %, Zscaler — на 5,5 %, SailPoint — на 9,4 %, Okta — на 9,2 %. Капитализация фонда Global X Cybersecurity ETF упала на 4,9 %. По оценкам Bloomberg, это связано с опасениями за будущее традиционных продуктов информационной безопасности на фоне развития новых сервисов на базе искусственного интеллекта. Причём, что важно, падение затронуло компании, основные продукты которых не связаны с анализом кода и безопасностью приложений (AppSec).
Но ещё сильнее снизился курс акций IBM — на 13,2 %. По мнению Reuters, это связано с тем, что на фоне развития новых сервисов «голубой гигант» может потерять такой значимый, по крайней мере, в США, бизнес, связанный с сопровождением ПО на языке COBOL (Common Business-Oriented Language, общий бизнес-ориентированный язык программирования).
COBOL, наряду с FORTRAN, — старейший язык программирования высокого уровня, созданный ещё в 1950-е годы. Одним из его создателей стала Грейс Хоппер. Он быстро набрал популярность среди авторов бизнес-приложений и, по некоторым данным, сохраняет пальму первенства до сих пор, во многом благодаря унаследованному багажу кода, который эксплуатируется по сей день. Так, на COBOL написана большая часть ПО платёжной системы Visa. Активно используют ПО на этом языке армия и флот США. На нём написана кадровая система вооружённых сил, которая эксплуатируется уже много лет и от которой не планируют отказываться.
Однако разработчиков, знающих COBOL, мало, и их услуги стоят дорого. IBM была практически монополистом в сфере сопровождения такого кода, большая часть которого работает на её мейнфреймах. Новые функции Claude способны разрушить эту монополию.
На этом фоне начали появляться апокалиптические прогнозы о будущем ИТ-отрасли. Одно из них выдал небезызвестный математик и экономист Нассим Талеб. По его мнению, стоит ожидать волны банкротств в ИТ-секторе, вызванных в том числе и влиянием сервисов с искусственным интеллектом. Особенно велики риски в высококонкурентных сегментах.
Начали появляться предостережения, связанные со снижением привлекательности профессии разработчика. В итоге отрасль рискует остаться без молодых кадров.
С другой стороны, немало и скептиков. Тем более что развитие искусственного интеллекта порождало избыточные ожидания, которые так и не сбылись. Кто из них прав?
Действительно прорыв или отголоски завышенных ожиданий?
Эксперты, опрошенные нами, оценили возможности нового Claude довольно неоднозначно. Большая их часть считает, что сделан большой шаг вперёд, но называть их прорывными несколько преждевременно.
С другой стороны, ИИ-ассистенты за последний год действительно достигли большого прогресса в работе над программным кодом. Так, известный специалист в области ИИ Андрей Карпаты, участвовавший в создании ChatGPT и Grok, в комментарии для издания The Decoder привёл такой пример. Если ещё в середине 2025 года на написание дашборда по анализу видео уходило 2 дня, то уже в конце года — около 30 минут.
Косвенно подтверждает рост «способностей» ИИ в написании кода и то, что такие инструменты начинают применять при создании вредоносных программ. Так, признаки использования ИИ были обнаружены в скриптах и утилитах группировки Forbidden Hyena. Раньше угрозу написания вредоносного кода с помощью ИИ считали сугубо теоретической из-за его низкого качества. Но, судя по всему, в конце 2025 года ситуация кардинально изменилась.
«Его преимущество понятно: огромное контекстное окно позволяет анализировать не отдельные сигнатуры или фрагменты, как это делают классические SAST-инструменты, а практически весь массив исходного кода целиком. За счёт механизмов reasoning модель способна находить известные уязвимости не только по формальным правилам, но и по логическим связям внутри системы. Подобный подход позволяет выявлять более сложные, контекстные дефекты», — делится личным опытом тестирования Claude Code Security руководитель направления разработки BPMSoft (ИТ-холдинг LANSOFT) Алексей Кононов.
Ведущий бизнес-аналитик ГК «Наносемантика» Егор Кириллов считает, что разработчики Claude Code Security вышли из старой парадигмы анализа кода и полностью изменили подход. От обычного статистического анализа они перешли к имитации работы квалифицированного инженера.
Как напомнил руководитель отдела аналитики и направления искусственного интеллекта компании Extyl Сергей Воробьёв, Claude Opus 4.6 нашёл более 500 давно скрытых уязвимостей. Причём в модель встроена защита от ложных срабатываний, которая довольно эффективна. В целом, по оценке Сергея, Claude Code Security — важное новшество в автоматическом анализе кода, но полноценная оценка его «прорывности» зависит от дальнейших тестов.
Руководитель направления ML Postgres Profexxional Савелий Батурин назвал сам факт того, что новый инструмент смог найти более 500 застарелых уязвимостей, многие из которых оставались незамеченными долгие годы, феноменальным результатом. Это стало закономерным следствием серьёзной работы над кодом, которую проделали в Anthropic.
Технический директор ИТ-группы N3.Tech Александр Чиченин назвал успехи Claude Code Security закономерным результатом усилий вендора, прежде всего направленных на то, чтобы выстроить вокруг своей большой языковой модели (LLM) обвязку из нужных инструментов, позволяющих получать необходимый и актуальный контекст для выявления целевых паттернов.
Заместитель руководителя направления «Т1 Искусственный интеллект» (ИТ-холдинг Т1) Сергей Карпович обратил внимание на то, что новый продукт Claude по анализу кода выявляет сложные уязвимости, учитывая понимание взаимодействия компонентов и отслеживание перемещения данных. Каждая проблема проходит многоуровневую проверку, прежде чем попасть к аналитику-человеку.
Однако среди экспертов доминируют всё же более сдержанные оценки. Так, директор по внедрению veai.ru Авенир Воронов назвал Claude Code Security удобным улучшением уже существующих инструментов для проверки кода на ошибки и уязвимости. А бизнес-партнёр по инновационному развитию ГК «Гарда» Лука Сафонов и вовсе назвал Claude Code Security «ещё одним статистическим анализатором», единственное отличие которого от аналогов состоит в наличии ассистента, повышающего удобство работы, но не дающего оснований считать данное решение отдельным классом.
Киберэксперт и инженер-аналитик компании «Газинформсервис» Екатерина Едемская напоминает, что Claude Code Security пока работает с большими ограничениями. Это означает, что технология ещё не прошла весь комплекс необходимых проверок, поэтому давать какие-либо оценки пока преждевременно.
Сергей Карпович согласен с тем, что оценивать новый инструмент станет возможным тогда, когда он будет реально интегрирован в процесс непрерывной разработки и контроля кода (CI/CD).
Когда ждать отечественных аналогов?
Исполнительный директор ELMA Наталья Долженкова видит главным слабым звеном российских продуктов именно специализированное обучение на кодовых корпусах и security-паттернах, а также экосистемную интеграцию во все этапы процесса разработки, включая CI/CD-конвейеры, процессы аудита, корпоративные политики безопасности. По уровню кода ядра LLM российские продукты находятся на сопоставимом уровне с западными.
«С точки зрения базовых технологий (LLM, code agents, статический и динамический анализ с применением искусственного интеллекта) разрыв не выглядит принципиальным — у многих команд уже есть сопоставимые наработки, хотя они могут уступать по масштабу данных, инфраструктуре и зрелости экосистемы. Поэтому вопрос не столько во времени, сколько в объёме инвестиций, доступе к вычислительным ресурсам и интеграции с инструментами разработки. При этом в отдельных нишах, например, в специализированном анализе безопасности кода, российские решения уже могут показывать сопоставимый уровень», — такую оценку дал директор департамента прикладных решений ЛАНИТ-ТЕРКОМ (входит в группу компаний ЛАНИТ) Дмитрий Медведев.
По оценкам опрошенных нами экспертов, на создание системы работы с кодом с возможностями, аналогичными тем, которые демонстрирует Claude Code Security, у отечественных разработчиков уйдёт от полугода до четырёх лет. Наибольший оптимизм проявил Авенир Воронов. По его мнению, уже в этом году стоит ждать решений от «Яндекса» или Сбера с сопоставимыми возможностями. Именно столько займёт процесс обучения и интеграция с наиболее востребованными инструментами. Технический директор компании «Стахановец» Сергей Щербаков также уточнил, что понадобится тонкая донастройка отдельных инструментов, которые уже реализованы в российских продуктах.
Схожей точки зрения придерживается также технический директор платформы «Боцман» (входит в «Группу Астра») Михаил Кобик. К слову, именно столько времени ушло на разработку самого Claude Code Security.
Александр Чиченин также допустил, что крупные отечественные игроки могут сделать продукт с сопоставимыми возможностями за год. Основной проблемой отечественных продуктов, однако, остаётся высокая стоимость и уровень зрелости, особенно в интеграциях. Положение к тому же усложняет сильная фрагментация технологического ландшафта в России.
Савелий Батурин считает реальным срок от года до двух. Это связано с тем, что у российских разработчиков меньше ресурсов. Особенно это касается работы с длинными контекстами, агентными пайплайнами, механизмами верификации, бенчмаркингом и различными интеграциями. А вот кодовую базу на базе решений с открытым исходным кодом можно создать быстро. По мнению Егора Кириллова, срок в два года возможен только при условии масштабных инвестиций в отечественную разработку.
Руководитель направления искусственного интеллекта в компании SimbirSoft Илья Фомичёв назвал фундаментальной причиной разрыва то, что российские LLM фокусируются на общей продуктивности написания кода, а не на глубоком семантическом поиске сложных уязвимостей. Чтобы его устранить, необходимо сконцентрироваться на фундаментальных проблемах: недостаток качественных датасетов на русском языке для решения задач информационной безопасности, нехватка вычислительных мощностей для обучения моделей такого масштаба и необходимость догонять быстро развивающиеся мировые решения. Для этого, по мнению Ильи Фомичёва, понадобится полтора-два года.
Екатерина Едемская считает главным сдерживающим фактором для быстрого создания отечественного аналога лидирующих продуктов доступ к оборудованию, прежде всего к графическим ускорителям, которые труднодоступны из-за санкционных ограничений и дефицита. Если данную проблему удастся решить, то готовое решение может появиться не более чем через 2 года.
Технический директор MD Audit (SL Soft FabricaONE.AI, акционер — ГК Softline) Юрий Тюрин наиболее осторожен в оценках. По его мнению, на решение данной задачи может уйти до четырёх лет. Это связано с необходимостью создания инфраструктуры, требуемой для обучения. Именно в этом российские, как и любые другие локальные разработчики, уступают основным международным игрокам. Основным сдерживающим фактором являются доступ к масштабируемым вычислительным ресурсам, объёмам качественных данных и накопленной инженерной практике оптимизации inference-контуров.
Директор по управлению проектами направления генеративного искусственного интеллекта «Рексофт» Юрий Шевченко также назвал среди факторов, замедляющих выход отечественных продуктов, время, необходимое для наработки практики. Без этого невозможно говорить о выигрыше в продуктовой гонке и создании по-настоящему зрелых моделей.
А вот генеральный директор «САЙБЕР Бизнес Консалтинг» Дмитрий Лившин считает, что просто бессмысленно говорить о создании продукта для поиска уязвимостей, пока нет работающих инструментов, позволяющих создавать работающий код. Ситуацию он проиллюстрировал с помощью рис. 1.
Рисунок 1. Уровень развития генерации кода и его анализа на ошибки и уязвимости
Также, как отметил Сергей Карпович, инструментарий анализа кода с ИИ повышает стоимость разработок на 30 %. Это делает их менее доступными прежде всего для небольших компаний.
Между тем, как показал опрос зрителей эфира AM Live «Практика применения ИИ и машинного обучения в ИТ и ИБ», около четверти из них использует LLM для анализа кода. Причём речь идёт о реальной практике, а не экспериментах.
Есть ли место для человека?
С самого начала новой волны внедрения искусственного интеллекта и роботизации широко распространились опасения, связанные с тем, что ИИ вытеснит людей из разных сфер. С появлением LLM на рубеже 2022–2023 годов они добрались и до сфер, связанных с разработкой и анализом кода.
Однако, как показала практика, внедрение высокоавтоматизированных средств скорее повышает потребность в кадрах. Другое дело, что вытесняемые специальности не совпадают с теми, спрос на которые растёт. В случае с анализом кода ситуация точно такая же.
По мнению Натальи Долженковой, расширение использования нейросетевых инструментов приведёт к смещению роли инженера с поиска синтаксических дефектов к управлению рисками и архитектурой. Как считает Илья Фомичёв, скорее всего, мы увидим связку «искусственный интеллект + человек», в которой LLM берёт на себя большую часть рутинных и отработанных кейсов, а эксперт — сложные и стратегические задачи.
Михаил Кобик полагает, что роль человека трансформируется от преимущественно инженерной до управляющей. Будут востребованы навыки управления ИИ, потребуется разработать процессы интеграции новых анализаторов в процессы разработки и тестирования кода, появятся задачи комплексной разработки и анализа кода с учётом архитектуры приложения.
О том, что внедрение ассистентов с искусственным интеллектом, применяемых для аудита программного кода, самым серьёзным образом может повлиять на подготовку кадров, говорили многие. В частности, участники круглого стола на конференции OS Day 2025 пришли к выводу, что ИИ резко сужает поле для деятельности так называемые джунов: стажёров, практикантов, просто молодых сотрудников, которым часто поручают работу, которая не требует высокой квалификации, но трудоёмка и скучна.
Среди таких задач, которые обычно делегировали джуниорам, — исправление простых уязвимостей, найденных сканерами, рефакторинг «кода с душком» (слишком длинные функции), первичная отладка и ряд других функций. По оценке Савелия Батурина, действительно, ИИ такие задачи выполняет лучше и быстрее, чем люди.
Те же выводы содержаться в статье «Переосмысление инженерной профессии для ИИ» технического директора Microsoft Azure Марка Руссиновича и вице-президента по связям с сообществом разработчиков Microsoft Скотта Хансельмана. По их наблюдениям, уже сейчас за счёт внедрения искусственного интеллекта занятость начинающих программистов падает, а число старших специалистов почти не меняется. Это создаёт угрозу для отрасли, поскольку сужает приток новых кадров.
Менеджеры Microsoft предложили компаниям ИТ-отрасли развивать программы наставничества для начинающих сотрудников, а не сужать сферу их деятельности. Надо сказать, что участники круглого стола на конференции OS Day, который прошёл за полгода с лишним до выхода статьи Марка Руссиновича и Скотта Хансельмана, пришли к тем же выводам. Также отечественные специалисты предлагали переключить джуниоров на решение других задач, например, на разметку данных для машинного обучения.
Авенир Воронов согласился с тем, что расширение использования LLM для анализа кода ещё больше снизит спрос на junior-специалистов. Другими «пострадавшими» он видит поставщиков сканеров кода, работающих по прежней парадигме.
С другой стороны, как подчеркнул Дмитрий Лившин, внедрение искусственного интеллекта в процесс поиска уязвимостей приведёт к тому, что его начнут применять те, кто раньше такой инструментарий просто никогда не использовал. Так что последствия будут налицо, особенно у небольших разработчиков, у которых порог входа в DevSecOps остаётся очень высоким. Для больших же проектов основной сложностью может стать максимальный размер контекста, с которым модель готова работать. Однако в целом в течение как минимум двух лет, по его оценке, о вытеснении людей из процесса отладки и контроля уязвимостей не может быть и речи.
Егор Кириллов, наоборот, считает, что беспокоиться не о чем:
«Каждый год мы слышим о замене людей в каких-либо сферах, но пока что этого не произошло. Нет умерших профессий, но есть сдавшие свои позиции на рынке. Если такое всё-таки произойдёт, то нас ждёт рост общей безопасности индустрии (примерно на 30–40 %) и ускорение разработки (15–20 %)».
Лука Сафонов считает, что до устранения проблем, связанных с галлюцинациями искусственного интеллекта, о вытеснении людей где бы то ни было говорить как минимум преждевременно. Так что пока даже джуниорам беспокоиться не о чем.
Екатерина Едемская также добавила проблему доверия к алгоритмам, по которым работают нейросетевые инструменты. Кроме того, она обратила внимание на то, что это обоюдоострый инструмент, который могут использовать и злоумышленники для поиска неизвестных уязвимостей, что способно породить своего рода «гонку вооружений» среди поставщиков моделей, а скорость их обновления станет критическим фактором. Но в любом случае любая автоматизация не снимает ответственности с человека. За людьми останется разбор сложных случаев, и никакой ИИ не сможет их оттуда вытеснить ещё довольно долго. Хотя Екатерина не исключила того, что с рынка аудита кода может быть вытеснено довольно много сотрудников, прежде всего занятых рутинными задачами.
Технический директор компании «Стахановец» Сергей Щербаков считает, что LLM является лишь инструментом, который хорошо выявляет типовые, шаблонные ошибки и уязвимости. Здесь остаётся место для человека, который будет заниматься анализом и валидацией проблем, найденных таким инструментом. Это затронет разработчиков, тестировщиков и специалистов по защите приложений, требования к уровню квалификации которых должны измениться.
Что изменится в регуляторике?
Безопасная разработка очень сильно влияет на сертификацию программного обеспечения, что часто является допуском во многие сегменты рынка. Соответственно, применение высокоавтоматизированных инструментов неизбежно повлияет на регуляторную практику.
Савелий Батурин напомнил, что регулярный статический анализ исходного кода (SAST) уже является обязательным условием в действующем стандарте безопасной разработки (РБПО), которого придерживается ФСТЭК России. И инструменты на основе LLM, скорее всего, будут рассматриваться как разновидность SAST.
Александр Чиченин назвал изменения в практике регуляторов сложным и многоплановым вопросом: «Необходима будет полная переработка „цепи доверия“ лицензированных и сертифицированных субъектов с добавлением в неё сертифицированных ML-акторов со сложными древовидными уровнями делегирования и верификации».
«Можно ожидать появления требований к журналированию работы AI-инструментов, к воспроизводимости результатов анализа и, возможно, к процедурам сертификации таких систем как вспомогательных средств контроля безопасности. Для крупных корпоративных клиентов это может стать даже преимуществом: автоматизированный аудит снижает барьеры доказательства соответствия стандартам», — такими видит направления для возможного регулирования Наталья Долженкова.
По мнению Авенира Воронова, регуляторы, включая Роскомнадзор и ФСТЭК России, могут даже лоббировать использование высокоавтоматизированных инструментов, возможно, каких-то определённых, для обязательного анализа кода на ошибки. Не исключено, что их применение станет обязательным для компаний, которые разрабатывают программное обеспечение для нужд государства или зарегулированных сфер вроде банковского сектора или объектов критической информационной инфраструктуры (КИИ). Обратной стороной станет излишняя регламентация и бюрократизация определённых процессов.
Как отметила Екатерина Едемская, при использовании высокоавтоматизированных инструментов возникает вопрос ответственности: кто виноват в пропущенной уязвимости — инженер по безопасной разработке или разработчики модели? Эти вопросы требуют как минимум уточнения со стороны регуляторов. Отдельная тема — конфиденциальность данных, и в ряде случаев, например, для работы с информацией ограниченного доступа, может потребоваться разворачивать всю инфраструктуру для работы LLM в корпоративном контуре. Это также может быть зафиксировано на уровне регуляторных норм.
По мнению Ильи Фомичёва, регуляторы могут ужесточить требования к процессам и обязать указывать в отчётах факт использования искусственного интеллекта при обнаружении инцидентов. Это связано с чётко зафиксированной позицией регуляторов, согласно которой ответственность всегда лежит на человеке.
«Регуляторы захотят видеть чёткое разделение: искусственный интеллект — это средство помощи, но решение и ответственность за него всегда остаются за человеком. Это станет обязательным условием для использования подобных технологий в тех сферах, где цена ошибки высока», — уточняет Сергей Щербаков.
Михаил Кобик назвал предметом регулирования также сами системы искусственного интеллекта. Егор Кириллов не исключил того, что выбор для определённых сфер применения может быть ограничен тем, что внесено в специальный реестр. Также, согласно предварительной версии закона, который будет регулировать использование ИИ в России, для многих сфер применение искусственного интеллекта будет ограничено отечественными моделями, их предполагается ранжировать по уровню локализации. Причём требованиям к «суверенным» моделям на настоящий момент не удовлетворяет ни одна из российских разработок.
Выводы
Действительно, в новую версию Claude были внесены как минимум существенные изменения, позволяющие заметно улучшить работу по аудиту программного кода. Эти нововведения могут серьёзно сказаться на развитии отрасли, прежде всего из-за слома многих подходов к подготовке молодых специалистов, поскольку искусственный интеллект способен выполнять те функции, которые обычно поручали практикантам, стажёрам и начинающим сотрудникам. Однако до полного вытеснения людей из данной сферы пока не может быть и речи. Кроме того, нейросетевые инструменты пока обходятся дороже людей.
С другой стороны, возможны серьёзные изменения в регуляторике, регламентирующей процессы безопасной разработки. Потребуется серьёзная переработка вопросов, связанных с тем, кто несёт ответственность за работу нейросетевых инструментов. Также встанет вопрос о том, какие сервисы считать доверенными, и об установке соответствующих критериев регуляторами.
