В современном мире разработки программного обеспечения дефицит квалифицированных кадров становится хроническим, а сложность систем растет по экспоненте. Одним из наиболее трудоемких этапов создания ПО остается написание юнит-тестов — небольших фрагментов кода, проверяющих работоспособность отдельных функций.
В новом выпуске подкаста Eye on AI ведущий Крейг Смит обсудил с Питером Шраммелем, сооснователем компании Diffblue, как искусственный интеллект и методы формальной верификации позволяют полностью автоматизировать этот процесс. Шраммель, имеющий академический бэкграунд в Оксфорде и опыт работы в Siemens, объяснил, почему написание тестов машиной — это не просто удобство, а необходимость для выживания современного бизнеса.
🧱 От ядерных станций к массовому коду: истоки технологии 1:32
Питер Шраммель начал свой путь в компьютерных науках в Вене, после чего работал в Siemens над системами RFID. Именно там он осознал, насколько сложно гарантировать корректность сложных систем. Это привело его к защите докторской диссертации по верификации систем во Франции, где он занимался формальными методами (mathematically proven implementation) для критически важных объектов: атомных электростанций и авиации .
Позже, в Оксфорде, работая с профессором Даниэлем Крёнингом, Шраммель сосредоточился на верификации программного обеспечения на языке C. В основе их подхода лежали логические ограничения (logical constraints) и поиск решений (solving). Эти техники, являющиеся одной из старейших областей ИИ, позволяют:
- Математически проверять, удовлетворяет ли программа заданным свойствам .
- Автоматически определять входные данные, необходимые для выполнения конкретной ветки кода (path coverage).
- Генерировать тестовые сценарии на основе анализа семантики языка .
Эти наработки легли в основу компании Diffblue, целью которой стало освобождение разработчиков от «рутины» написания тестов в пользу творческих задач.
🧪 Анатомия юнит-теста и проблема «легаси» 4:14
Юнит-тест (модульный тест) — это проверка минимальной части кода, например, одного класса в Java . Традиционно считается, что тесты должны писаться одновременно с кодом или даже до него (методология TDD, Test-Driven Development). Однако, по наблюдениям Шраммеля, «чистый» TDD в индустрии встречается редко .
Основные проблемы современного ПО:
- Замедление разработки: В крупных проектах часто полагаются на сквозные (end-to-end) тесты. Они надежны, но выполняются слишком долго, что мешает быстрому выпуску обновлений .
- Наследие (Legacy code): Огромные массивы старого кода (например, на COBOL) вообще не имеют юнит-тестов .
- Страх изменений: ПО не статично; оно требует поддержки и обновления. Без тестов любое изменение в старом коде чревато появлением багов, которые первыми обнаружат клиенты, что бьет по репутации компании .
🧠 Обучение с подкреплением против языковых моделей 11:18
Главный продукт компании — Diffblue Cover — пишет тесты полностью автономно. В отличие от популярных сегодня инструментов на базе больших языковых моделей (LLM), таких как GitHub Copilot, Diffblue использует иной подход.
Шраммель объясняет, что разработка ПО по сути является математически определенной средой. Diffblue применяет алгоритмы обучения с подкреплением (Reinforcement Learning) для поиска в гигантском пространстве возможных вариантов тестов . Это работает по аналогии с системой AlphaGo:
- Инструмент анализирует метод в коде пользователя.
- Система «прощупывает» пространство поиска, генерирует варианты тестов и оценивает их.
- Функция вознаграждения (reward function) учитывает не только покрытие кода (coverage), но и «эстетику» . Тест должен выглядеть так, будто его написал человек, чтобы разработчику было привычно его читать и дополнять. Шраммель называет это «тестом Тьюринга для кода» .
В сравнении с ИИ-помощниками типа Copilot, которые точны примерно на 50% и требуют человеческого контроля, Diffblue нацелена на полную автономность .
Технические ограничения и безопасность
Многие клиенты Diffblue запрещают передачу своего кода в облако. Поэтому инструмент работает за файрволом заказчика. Это накладывает жесткие рамки:
- Время: На генерацию теста для одного метода отводится в среднем 1 секунда .
- Детерминизм: При одинаковом коде система всегда должна выдавать одинаковый результат.
- Локальность: Весь процесс обучения и генерации происходит локально на ресурсах клиента.
🔮 Будущее: создание программ на естественном языке 21:02
На вопрос Крейга Смита о том, когда мы сможем диктовать компьютеру условия текстом и получать готовые сложные системы, Питер ответил осторожно. По его мнению, главная сложность — не в написании кода, а в устранении двусмысленности требований .
- Человеческие инструкции в реальном мире всегда расплывчаты.
- Для создания работающего ПО необходим диалог (incremental refinement) между человеком и ИИ.
- Машина должна уметь задавать уточняющие вопросы: «А что должно произойти в этой конкретной ситуации, о которой вы не упомянули?» .
Шраммель полагает, что мы увидим постепенную эволюцию, а не мгновенную революцию. Полная автоматизация сложного программирования на естественном языке, по его прогнозу, может занять несколько десятилетий .
📈 Экономический эффект автоматизации 25:53
Опрос, проведенный Diffblue два года назад, показал, что разработчики тратят до 35% своего времени только на тестирование . Автоматизация этого этапа эквивалентна найму на треть большего количества сотрудников.
При этом Шраммель не верит в массовые увольнения программистов. По его словам:
- Спрос на ПО безграничен, и компаний всегда будет не хватать текущих мощностей .
- Растет популярность Low-code и No-code инструментов. Gartner прогнозирует, что к 2024 году 65% приложений будут создаваться без классического кодинга .
- Разработчики просто переместятся на более высокий уровень абстракции, занимаясь архитектурой и логикой, а не написанием рутинных проверок.
