Sonar утверждает, что его инструменты используют 75% компаний из Fortune 100, а платформа ежедневно анализирует более 750 млрд строк кода. На этом фоне верификация AI-кода перестает быть скучной темой для отдела контроля: в банках, медицине, страховании и госсекторе именно она решает, станет ли ИИ ускорителем разработки или новым источником аудиторской боли.
Об этом сообщает The New Stack в колонке Екатерины Окуневой, Product Marketing Manager в Sonar, опубликованной 23 июля 2026 года. Текст важен не только как еще одна проповедь про «агентов, которые пишут код», а как симптом более приземленного сдвига: regulated-компании уже не спорят, нужен ли им AI-assisted development, они пытаются понять, как встроить его в процессы так, чтобы потом не объясняться с безопасниками, аудиторами и регуляторами.
Кодогенерация ускоряется, проверка отставать больше не может
Главный тезис материала звучит просто: в регулируемых отраслях рост скорости разработки сам по себе ничего не значит, если вместе с ним пропорционально растут операционные, security- и compliance-риски. Банки хотят быстрее автоматизировать внутренние процессы, не растягивая и без того длинные инженерные бэклоги. Медицинские организации хотят быстрее превращать клиническую экспертизу в рабочие инструменты для врачей и пациентов. Производственные компании, страховщики и госструктуры хотят ПО, которое отражает их реальные правила и ограничения, а не логику коробочного продукта, к которому бизнес должен подстраиваться.
ИИ, по мысли автора, закрывает старую проблему дефицита разработки: люди, которые лучше всех понимают бизнес-процесс, обычно находились дальше всех от кода. Врач знает, где ломается маршрут пациента. Актуарий понимает, какие правила должен применять андеррайтинговый движок. Специалист по комплаенсу лучше многих видит, где цифровой процесс рискует потерять юридически важную деталь. Раньше между этим знанием и продакшеном стояла длинная цепочка переводов: от бизнес-потребности к требованиям, от требований к дизайну, от дизайна к реализации. На каждом этапе терялся смысл. AI-assisted development, как пишет The New Stack, укорачивает эту дистанцию: domain experts могут точнее описывать логику и раньше включаться в прототипирование, а инженеры снимают с себя часть рутины вроде boilerplate, документации, каркасов тестов и навигации по незнакомому коду.
Но тут и начинается неприятная часть. Чем больше участников получают доступ к созданию ПО, тем важнее становится не «героическая» ручная проверка в конце, а системная верификация AI-кода по всему циклу. Ошибка, которую внес агент, не становится менее опасной только потому, что ее сделал не человек. Захардкоженный секрет, уязвимая зависимость, ненадежная реализация или трудно сопровождаемый кусок логики одинаково плохо выглядят и в глазах аудитора, и в постмортеме после инцидента. Для regulated-среды это особенно чувствительно: там, по выражению автора, у каждой строки кода выше шанс «встретиться с аудитором».
От ассистентов к агентным циклам
В колонке отдельно отмечен сдвиг от одиночных AI-подсказок к агентным циклам разработки. Речь уже не только о том, что модель дописала функцию или сгенерировала тест. Агенты берут на себя длинные задачи: изучают репозиторий, предлагают план, пишут и переписывают изменения, запускают инструменты, а затем доходят до pull request. Это меняет саму операционную модель команд. Если код начинает производиться не эпизодически, а сериями полуавтономных итераций, то компании нужны не разрозненные сканеры и чек-листы, а механизм, который дает агенту правильный контекст, проверяет результат в нужных точках и возвращает замечания обратно в цикл исправления.
Для этого Sonar продвигает схему Agent Centric Development Cycle, или AC/DC. Ее смысл не в очередной красивой аббревиатуре, а в трех связках: Guide, Verify, Solve. Сначала агентам задают правила и стандарты до начала работы. Затем результат проверяют во время генерации и перед попаданием в основную ветку. После этого найденные проблемы не оседают в тикетах мертвым грузом, а возвращаются в контур исправления. Иначе говоря, в regulated-компаниях проверка должна быть не финальным шлагбаумом, а постоянной инженерной способностью. Именно это автор называет более реалистичным способом ускорять разработку без потери контроля.
Отдельно материал бьет по популярному организационному мифу, будто комплаенс живет где-то сбоку от инженерии и мешает «нормально работать». Окунева пишет обратное: значительная часть compliance-требований на деле совпадает с банальной хорошей разработкой. Безопасное кодирование, управляемые изменения, исправление уязвимостей, прозрачность зависимостей, контроль доступа, сохранение доказательной базы по релизам и проверкам — это не параллельная бюрократия, а свойства зрелого SDLC. Проблема не в том, что команды не знают этих правил. Проблема в том, что их трудно применять стабильно на сотнях и тысячах изменений, особенно когда ИИ увеличивает объем кода быстрее, чем люди успевают его просматривать вручную.
Здесь и появляется самый практичный тезис для CTO, engineering manager и CISO: если проверка встроена в delivery pipeline, то доказательства для комплаенса возникают как побочный продукт обычной работы команды. Результаты pull request, статусы гейтов, история ремедиации, тестовые прогоны, approvals перед релизом — все это становится не разовой подготовкой к аудиту, а живым следом того, что контроль действительно работает постоянно. Для разработчиков это означает меньше ручной рутины и меньше споров в духе «мы двигаемся слишком быстро». Для бизнеса — более честный разговор о риске: вопрос уже не в скорости как таковой, а в том, автоматизированы ли нужные контроли и насколько они эффективны.
Слабое место текста тоже видно: это спонсорская публикация Sonar, поэтому в ней нет независимых цифр по рынку, сравнений с альтернативными подходами и кейсов с измеримым эффектом вроде сокращения времени вывода релиза или числа инцидентов. Но даже с этой поправкой месседж попадает точно в нерв 2026 года. AI coding assistants больше не воспринимаются как игрушка для прототипов, а агентные сценарии все чаще упираются не в генерацию, а в проверку. Похоже, следующий виток конкуренции в enterprise-разработке пройдет не между теми, кто пишет код быстрее, а между теми, кто сумел превратить верификацию AI-кода в часть конвейера, а не в пробку перед продом.