Проверка кода AI: главный навык разработчика

Большинство материалов по AI-разработке сосредоточено на промптинге. Какие модели использовать? Какие промпты дают лучший результат? Как сделать агентов более автономными? Эти вопросы предполагают, что узкое место — качество генерации. Это предположение ошибочно. Настоящее узкое место — верификация.

AI-системы превосходно выдают ответы, которые кажутся правильными. Они чисто форматируют код, пишут уверенные объяснения, звучат авторитетно. Но уверенность не равна корректности. Ловушка работает так: вы задаёте вопрос AI, получаете уверенный ответ, предполагаете, что он верен, и строите работу на его основе. Ошибка накапливается. Это AI-ловушка проверки.

Самая опасная часть — не первая ошибка, а слои работы на непроверенном предположении. Для джуниоров, self-taught разработчиков и тех, кто меняет карьеру, эта ловушка особенно дорога: каждый непроверенный ответ может стать проблемой в production, часом отладки или пустой тратой времени. Этот гайд утверждает: важнейший навык в AI-assisted разработке — не промптинг, а верификация.

Проблема уверенности AI

AI не знает, когда он ошибается. Это не дефект какой-то модели — так работают эти системы: они предсказывают токены, а не проверяют истину. Когда AI генерирует код, он делает это с той же уверенной интонацией, независимо от корректности.

Примеры:

Несуществующие API

user = stripe.customers.get_by_email("user@example.com")

Метод get_by_email не существует. Реальный Stripe API требует list с фильтром email. Джуниор потратит 20 минут на отладку, прежде чем поймёт, что сам вызов API неверен.

Устаревшие методы

AI может использовать метод из React 16, удалённый в React 18. Код выглядит нормально, компилятор может даже принять часть, но runtime поведение сломано.

Неправильные имена пакетов

AI предлагает stripe-node вместо stripe или aws-sdk-v3 вместо @aws-sdk/client-s3. Установка падает или ставит не ту библиотеку.

Неверные паттерны фреймворков

AI генерирует API-роут Next.js устаревшим паттерном, который ломается в Next.js 14, или структуру компонента Vue 2 для проекта на Vue 3. Код синтаксически верен, но архитектурно неверен.

Неверная конфигурация

AI рекомендует IAM-политику с устаревшим именем действия, или Docker Compose с синтаксисом старой спецификации. Файл выглядит правильно, но падает в runtime.

Проблемы безопасности

AI генерирует код, который работает, но раскрывает секреты в переменных окружения, доступных клиенту, или создаёт endpoint без аутентификации, или форму без валидации. Функциональность работает, но безопасность нарушена.

Устаревшие ссылки на документацию

AI ссылается на опцию конфигурации, удалённую в последней версии инструмента, или на CLI-флаг, которого больше нет. Объяснение звучит авторитетно, но реальная команда падает.

Сломанная бизнес-логика

AI генерирует код, который проходит проверку типов и компилируется, но реализует неверное бизнес-правило: скидка округляется неправильно, сравнение дат использует не тот часовой пояс, фильтр исключает валидные записи.

Проблема не в том, что эти ошибки существуют — люди тоже ошибаются. Проблема в том, что AI подаёт каждый ответ с той же отполированной уверенностью. Правильный и неправильный код выглядят одинаково, пока вы их не проверите.

Генерация vs Верификация

AI ускоряет генерацию: написание кода, объяснений, документации, предложение решений, архитектур, шаблонов, тестов, конфигураций. Генерация дешева — AI может выдать тысячи строк за секунды.

Верификация создаёт ценность: запуск кода, тестирование, чтение логов, проверка выходов, пересмотр предположений, сравнение с документацией, тестирование граничных случаев, валидация безопасности, подтверждение бизнес-логики, проверка состояний ошибок, тестирование пользовательских потоков. Верификация дорога — требует времени, внимания и понимания.

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

Вот различие:

• Генерация: AI пишет 100 строк кода. Верификация: Вы запускаете код.
• Генерация: AI объясняет API. Верификация: Вы читаете официальную документацию.
• Генерация: AI предлагает конфигурацию. Верификация: Вы тестируете конфигурацию.
• Генерация: AI предлагает решение. Верификация: Вы проверяете, что решение работает.
• Генерация: AI генерирует компонент. Верификация: Вы тестируете компонент в браузере.
• Генерация: AI создаёт миграцию. Верификация: Вы проверяете миграцию в staging.
• Генерация: AI пишет тест. Верификация: Вы проверяете, что тест падает, когда должен.

Генерация — отправная точка. Верификация — работа.

Почему сеньоры ловят больше ошибок AI

Опыт часто выглядит как интеллект. Сеньор просматривает AI-код и сразу замечает проблемы: «Это сломается в production, потому что таймаут слишком короткий», «Эта конфигурация вызовет проблемы с памятью под нагрузкой», «Эта миграция заблокирует таблицу». Это не магия — это распознавание паттернов. Сеньоры уже видели эти сбои: системы аутентификации, падающие при деплое, миграции БД, вызывающие даунтайм, ошибки конфигурации, ломающие мониторинг, проблемы безопасности, обнаруженные в production.

Джуниоры могут намеренно развить этот навык. Метод прост: проверяйте всё, пока проверка не станет инстинктом. Со временем вы начнёте замечать паттерны и думать: «Я уже отлаживал эту ошибку». Инстинкт не заменяет проверку, но сигнализирует, что проверять в первую очередь.

Реальные сценарии сбоев AI

Галлюцинация API

# AI-сгенерированный код: несуществующий метод
user = stripe.customers.get_by_email("user@example.com")

# Правильный код:
customers = stripe.customers.list(email="user@example.com", limit=1)
user = customers.data[0]

Почему опасно: галлюцинированный метод выглядит корректно, следует конвенциям JavaScript. Разработчик может скопировать его, предположить, что он работает, и обнаружить проблему только в runtime. Шаг проверки: сверьтесь с документацией Stripe API.

Ошибка конфигурации облака

AI генерирует политику bucket S3 для статического хостинга. Политика выглядит разумно, синтаксис верен, объяснение уверенное. Проблема: политика даёт больше прав, чем нужно — разрешает листинг всех объектов, а не только чтение конкретных. Это риск безопасности. Шаг проверки: изучите документацию AWS по минимальным правам, протестируйте политику в AWS Policy Simulator.

Упущение безопасности

# AI-сгенерированный код: пароли в открытом виде
def register_user(username, password):
    # Oпасно: пароль хранится как есть
    db.users.insert_one({"username": username, "password": password})
    return {"message": "User created"}

Проблема: пароли хранятся в открытом виде, API возвращает хеши паролей клиенту, нет rate limiting на входе. Код работает, пользователи могут войти, но безопасность нарушена. Шаг проверки: используйте bcrypt для хеширования, не возвращайте чувствительные поля, добавьте rate limiting.

Фронтенд работает, пользователь страдает

# AI-сгенерированный компонент React без валидации
function Form() {
    const [email, setEmail] = useState('');
    const handleSubmit = (e) => {
        e.preventDefault();
        fetch('/api/submit', { method: 'POST', body: JSON.stringify({ email }) });
    };
    return (
        

             setEmail(e.target.value)} />
            Submit
        
    );
}

Проблема: форма не валидирует ввод перед отправкой, не показывает ошибки, нет состояния загрузки, форма недоступна с клавиатуры. Компонент технически работает, но UX сломан. Шаг проверки: протестируйте форму в браузере с невалидными данными, отправьте форму, проверьте навигацию с клавиатуры, используйте инструменты доступности.

Рабочий процесс проверки

Проверка должна быть повторяемым процессом. Вот практический workflow, который можно использовать сразу:

1. Прочитайте всё. Перед запуском AI-кода прочитайте его. Ищите незнакомые имена методов, необычные значения конфигурации, комментарии, противоречащие коду, захардкоженные значения, отсутствие обработки ошибок.
2. Проверьте документацию. Если AI ссылается на API, пакет, метод фреймворка или опцию конфигурации — проверьте официальную документацию. Сравните сигнатуры методов, имена параметров, типы возврата, deprecation notices, совместимость версий.
3. Запустите тесты. Если в проекте есть тесты — запустите их. Если AI сгенерировал новый код — напишите тесты для него. Если AI утверждает, что код корректен, проверьте, что тесты падают, когда должны.
4. Проверьте логи. Запустите код и прочитайте логи. Ищите предупреждения, deprecation notices, сообщения об ошибках, неожиданный вывод. Логи честнее объяснений.
5. Валидируйте выходы. Проверьте, что код даёт ожидаемый результат. Не просто что он работает без ошибок — что вывод корректен. Тестируйте happy path, граничные случаи, случаи ошибок, null-значения, пустые входные данные.
6. Пересмотрите предположения. AI делает предположения: база данных всегда доступна, API всегда отвечает менее чем за секунду, пользователь всегда аутентифицирован, ввод всегда валиден, сеть всегда надёжна. Составьте список предположений и проверьте каждое.
7. Протестируйте в браузере пользовательские изменения. Если код влияет на UI, откройте его в браузере. Проверьте разные разрешения экрана, состояния загрузки, пустые состояния, обработку ошибок, клавиатурную навигацию.

Практический вывод

AI — мощный инструмент генерации, но его главная ловушка — уверенность без корректности. Разработчики, которые преуспевают с AI, не те, кто пишет лучшие промпты, а те, кто быстрее и надёжнее проверяет результат. Начните прямо сегодня: перед каждым использованием AI-сгенерированного кода выполняйте хотя бы один шаг из рабочего процесса проверки. Со временем верификация станет привычкой, и вы будете тратить меньше времени на отладку и больше — на создание ценности.