Почему я создал open-source сканер AST, чтобы застраховать свой AI-сгенерированный код

Введение

Последние пару лет я активно использую AI-ассистентов для генерации кода. Это похоже на суперсилу: пишешь промпт — и получаешь рабочий фрагмент на TypeScript, Python или Go. Но чем больше я полагался на такие инструменты, тем тревожнее становилось. Код выглядит убедительно, проходит линтеры, но иногда содержит глубокие логические ошибки, которые всплывают в самый неподходящий момент. Однажды такой баг уронил продакшен в моём пет-проекте, и я понял: нужен инструмент, который будет проверять именно те ошибки, что свойственны AI-генерации. Так родился open-source сканер AST.

Vibe coding — термин, который всё чаще звучит в индустрии, — означает написание кода в диалоге с нейросетью, когда разработчик скорее направляет, а не пишет каждую строчку. Это невероятно продуктивно, но несёт скрытые риски. В этой статье я расскажу, почему принял решение сделать собственный инструмент, как он работает, какие результаты дал и почему верифицировать сгенерированный код — критически важный шаг.

Проблема: доверять, но проверять

AI-код стал неотъемлемой частью многих пайплайнов. По данным отчётов, опубликованных GitClear, доля кода, созданного с помощью ассистентов, выросла за последние годы в разы, но при этом качество кода в репозиториях не всегда улучшалось. Компания отметила увеличение количества «закоммиченного мусора» и дублирования. Это не значит, что AI плох — он просто не понимает контекста. Он генерирует паттерны, которые выглядели правдоподобно на обучающих данных, но не всегда корректны для вашей кодовой базы.

Я столкнулся с конкретными проблемами:

• Логические ошибки: нейросеть писала условие с неверным порядком проверок, из-за чего пользователь попадал в несуществующий сценарий.
• Небезопасные конструкции: например, использование eval или некорректная обработка пользовательского ввода, что вело к уязвимостям.
• Несоответствие API: вызов функции с параметрами, которые не соответствуют реальной сигнатуре библиотеки.
• Игнорирование edge-кейсов: отсутствие проверки на null, undefined или пустые массивы.

Традиционные линтеры (ESLint, Pylint) отлично ловят синтаксические ошибки и отступы, но они не понимают семантику. Типы могут не совпадать, а линтер смотрит только на стиль. Поэтому я начал искать (и не нашёл) инструмент, который фокусировался бы на характерных ошибках AI-генерации, а не на стиле. Тогда и решил написать такой сам.

Решение: open-source сканер AST

AST — это абстрактное синтаксическое дерево. Когда парсер читает исходный код, он превращает его в структуру, где каждый узел обозначает конструкцию: переменную, цикл, вызов функции. Анализируя это дерево, можно выявлять несоответствия, которые не видны при поверхностной проверке.

Мой сканер выполняет несколько проходов по AST:

1. Построение дерева — на входе исходный код, на выходе дерево. Для этого я использую библиотеку tree-sitter, которая поддерживает множество языков и даёт точный разбор даже при наличии синтаксических ошибок.
2. Семантический анализ — проверка типов, поиск потенциально опасных вызовов, проверка обработки исключений.
3. Проверка на паттерны AI-ошибок — вот здесь самое интересное. Например, если AI сгенерировал if (user) { ... } без else, сканер может выдать предупреждение, если в контексте это может привести к пропуску действия.

Инструмент написан на Python и упакован в CLI, который легко встроить в CI/CD. Я назвал его ast-scan-gen и выложил в open-source на GitHub. Почему open-source? Во-первых, я верю в прозрачность. Во-вторых, коллективный разум помогает быстрее находить новые паттерны ошибок. В-третьих, это способ внести вклад в экосистему, которая так быстро меняется.

Кейс-стади: как я применял сканер на двух проектах

Чтобы проверить эффективность, я применил сканер к двум своим проектам. Первый — веб-приложение на TypeScript (SaaS-дашборд), второй — микросервис на Python для обработки платежей. В обоих значительная часть кода была сгенерирована с помощью ChatGPT и GitHub Copilot.

Проект 1: TypeScript дашборд

В коде TypeScript сканер нашёл 47 потенциальных проблем, из которых 22 были критическими. Вот типичный пример:

function getUser(id: number) {
  const user = await db.find(id);
  // AI сгенерировал `return user` без проверки
  return user.name; // TypeError: Cannot read property 'name' of null
}

Сканер, анализируя AST, увидел, что после асинхронного вызова нет проверки на null, и сгенерировал предупреждение. После исправления таких мест количество ошибок, которые пользователи видели в интерфейсе, сократилось примерно на 30%.

Проект 2: Python микросервис

В Python-коде было ещё интереснее. Сканер обнаружил несколько мест, где использовался eval() для обработки строк, поступающих из внешнего источника. Это классическая уязвимость, которую можно эксплуатировать. ИИ нередко генерирует такие конструкции, если они встречаются в его тренировочных данных. Сканер пометил их как «high risk».

Всего было выявлено 63 проблемы в этом микросервисе, из которых 12 — уязвимости. После того как мы их устранили, нагрузочное тестирование показало, что количество 500-х ошибок упало на 27%.

Таблица результатов

Почему именно AST, а не просто регулярки

Многие спрашивают: почему не использовать обычный регулярный поиск или более простые эвристики? Ответ прост: регулярные выражения не понимают контекст. AST позволяет проверять, что if-конструкция действительно охватывает все нужные ветви, что тип переменной соответствует ожидаемому, что вызов функции не приводит к переполнению стека. Это семантический анализ, а не поиск по шаблону.

Например, в TypeScript проверка на null может выглядеть как if (!user), а может быть if (user === null). Для регулярного выражения это два разных паттерна. AST видит одно и то же: проверка наличия объекта. Такой подход значительно снижает количество ложных срабатываний.

Как я интегрировал сканер в рабочий процесс

Чтобы не увеличивать время сборки, я сделал сканер узкоспециализированным и быстрым. Он обрабатывает около 10 000 строк кода за 2 секунды на моём ноутбуке. В CI/CD он запускается параллельно с юнит-тестами и занимает меньше 3% времени всего пайплайна.

Я добавил его в pre-commit hook для локальной проверки и в GitHub Actions для пулл-реквестов. Когда приходит PR с AI-кодом, сканер автоматически комментирует проблемные места. Это экономит время ревьюера и не даёт багам просачиваться в основную ветку.

Кстати, для автоматизации ревью я также использую возможности платформ вроде GitHub. Например, можно настроить уведомления, но именно собственный сканер даёт, на мой взгляд, самый глубокий анализ, так как вы можете обучать его на своих паттернах ошибок.

Результаты и выводы

За первый месяц использования сканера я исправил более 50 реальных ошибок в своих пет-проектах. Уверенность в коде, который генерирует AI, значительно выросла. Теперь я могу отпустить процесс написания кода на автопилот, зная, что на выходе есть страховочная сетка.

Но самое приятное — это реакция сообщества. Когда я выложил инструмент в open-source, я получил десятки pull request с новыми правилами проверки. Один разработчик предложил детектор «перевёрнутых условий», другой — проверку на устаревшие API. Это подтверждает, что проблема универсальна.

Заключение

AI-генерация кода неизбежна. Мы стоим на пороге эпохи, когда большинство разработчиков будут писать не код, а промпты. Но это не отменяет ответственности за качество. Использование инструментов вроде моего сканера AST — это не недоверие к AI, а забота о пользователях. Если вы тоже активно пользуетесь AI в разработке, рекомендую присмотреться к таким решениям или написать свои.

Сканер AST — это не панацея. Он не заменяет code review и тесты. Но он отсекает значительную часть типичных ошибок, позволяя разработчику сосредоточиться на действительно сложных вещах. Если вы попробуете использовать подобные инструменты, вы увидите, насколько спокойнее становится работа с AI.

Для тех, кто хочет глубже разобраться в интеграции AI в свои процессы, я рекомендую обратить внимание на образовательные материалы. Например, ASI Biont поддерживает подключение к GitHub и другим сервисам через API — подробнее на asibiont.com/courses. Там можно найти практические руководства по автоматизации и контролю качества в эпоху AI. Попробуйте, это может стать вашим следующим шагом к осознанному применению генеративных моделей в разработке.