Обещания и риски ИИ в разработке кода

Мы переживаем настоящий бум в разработке ПО. Модели вроде больших языковых систем пишут рабочий код за секунды. GitHub Copilot или Claude уже в арсенале миллионов разработчиков. Но за этой скоростью скрывается подвох: код запускается, а делает ли он именно то, что нужно?

Проблема стара как мир. Команды всегда спорили: что хочет заказчик и что выходит у инженеров. ИИ просто усиливает это в разы. Человеческие ошибки ловят знания и доработки. А ИИ генерит тысячи строк мгновенно — и промахи множатся.

Разрыв между замыслом и кодом

Суть в том, что обычный язык размыт. Просишь ИИ "проверить email пользователя" — и что он поймёт?

• Формат по RFC 5322?
• DNS-запрос на реальный домен?
• Рассылка ссылки на подтверждение?
• Всё сразу, плюс обработка ошибок?

ИИ угадывает. Иногда попадает. Чаще — нет. А без коллеги на ревью ошибки накапливаются в сотнях функций. Разрыв между "хочу так" и "работает вот так" всегда был. Но сейчас он огромен и ускоряется.

Спектр формализации замысла

Не дели на "формально" или "нет". Подходи по спектру — под задачу.

Лёгкий уровень: тесты для уточнения

Часто хватит простых тестов, чтобы поймать косяки:

# ИИ сгенерировал валидатор email
# Тесты покажут, что имелось в виду

def validate_email(email):
    assert validate_email("user@example.com") == True
    assert validate_email("user@localhost") == False  # Только реальные домены
    assert validate_email("invalid.email") == False

Пиши тесты заранее, показывай ИИ — и всё сходится. Это test-driven подход: быстро, но чётко.

Средний уровень: постусловия

Дальше — точные гарантии после выполнения:

# Постусловие для перевода средств
def transfer_funds(from_account, to_account, amount):
    """
    Гарантии:
    - баланс from_account минус amount
    - баланс to_account плюс amount
    - общий баланс без изменений
    - атомарность (всё или ничего)
    """

ИИ на таких примерах ловит баги, которые тесты пропускают. Инварианты и края — его стихия.

Тяжёлый уровень: доказуемая синтетика

Вершина — DSL и верификация. Код не тестируют, а доказывают. Не для всего. Но в крипте, финансах, авиации, медицине — must have. Ошибки там стоят жизней или миллиардов.

Бутылочное горлышко: кто проверяет спецификацию?

Правда такова: пользователь — единний оракул для specs. Код по спецификации проверишь. А спецификация верна? Идеальный код под неверный запрос — провал.

Нужен симбиоз человека и ИИ. Ключ:

• Циклы обратной связи для доработки specs
• Примеры и тесты как прокси для пробелов
• Метрики качества specs без запуска кода
• Простые паттерны без докторской по теоремам

Что это значит для твоего стека

Если крутишь продакшн, меняй архитектуру.

На этапе генерации

Бери ИИ, который спрашивает уточнения или тесты. "Рабочий код без проверки" = фабрика багов.

В CI/CD

Генерированный код — под лупу. Постусловия, property-based тесты. Для критичного — верификация в merge-гейтах.

В команде

Разрабы с ИИ учатся писать specs. Это стараяスキル, просто спящая. Ревью — код + specs.

Что изучают исследователи

Тема горячая: ИИ + формальные методы + HCI. Результаты радуют:

• Test-driven поднимает корректность
• ИИ-генерированные постусловия хватают реальные баги
• Пайплайны с доказательствами — из prose в verified code

Открыто: масштабирование, композиция, удобный интерфейс, сложная логика.

Куда дальше

Будущее не в "больше кода быстрее". В правильном коде под ключевые нужды.

Формализация — мостик. Не меняй текст на матан. Создавай способы проверки, что замысел в prose, тестах или примерах воплотился верно — для людей и машин.

Для dev'ов, стартапов и infra-команд на NameOcean это актуально: проверка deployment specs, гарантии DNS-конфигов, верифицированные workflow'ы SSL вместо "протестировали и забыли".

В проде выживает не самый хитрый код. Самый осознанный.