Глава 1. Шаман обещает 🔮 и приносит хаос 💥

Суть за десять секунд (шаман бы бубнил до заката). ⏱️Большие языковые модели дали разработке скорость, но забрали предсказуемость. Это эссе о том, почему инженерные контракты играют в этой паре роль взрослого в комнате — или, как привычнее звучало у костра, старейшины, — почему Java остаётся одним из самых зрелых способов эти контракты реализовать и что всё это меняет для QA-инженера.

Индустрию разработки раскололо надвое, как кремень об кремень. С одной стороны — хор энтузиастов: модели пишут код, генерируют документацию и «дописывают» тесты с той уверенностью, с которой джуниор отвечает «да-да, я знаю», а шаман — «духи будут благосклонны». С другой — старые добрые принципы инженерии: контракты, воспроизводимость, контроль качества. То, что в пещере называлось «сначала проверь яму, потом прыгай». 🎭Для QA-инженера, привыкшего опираться на факты, а не на толкование снов, ответ звучит неожиданно консервативно: инженерные контракты.

Java в этой пьесе — не звезда и не единственный герой, но очень убедительный суфлёр: без неё актёры забывают слова уже на середине второго акта. Строгая типизация, валидация и схемы есть в Kotlin, C#, TypeScript, Rust и Go, а в Python — через Pydantic и mypy. Но в enterprise-контуре Java исторически даёт самую зрелую и скучную (в хорошем смысле) инфраструктуру для таких контрактов. 🦣Скучную — потому что она работает. А работающий мамонт лучше нарисованного.

Хаос не абстрактен — он проявляется в вещах, знакомых каждому автотестеру. Возьмём генерацию тест-кейсов: модель выдаёт красивый список шагов, но упускает граничные условия, потому что «так логичнее». Сегодня она предложит один набор проверок, завтра — другой, с той же уверенностью в голосе. 🥱А тест обязан быть воспроизводимым: если его результат зависит от настроения модели, он превращается в лотерею.🎲

Баг проходит мимо не потому, что его не поймали, а потому, что его никто не искал. Модель не врёт — она просто живёт в параллельной вселенной, где требования всегда такие, как ей удобно.🥁

Случай был показательный и слегка унизительный😅. Модель сгенерировала проверки для формы оплаты, и все они гордо позеленели в CI. Через неделю в проде всплыл баг: ни один тест не проверял минимальную сумму платежа. Модель «не подумала» про редкий кейс, а я слишком доверился её аккуратному списку.🤨

Уточню формулировку, чтобы не обижать машину: у модели нет намерения, нет модели мира и нет злого умысла. Есть стохастичность, ограниченный контекст и оптимизация под правдоподобие ответа. Поэтому она ошибается уверенно и красиво — как консультант, который отвечает, не слушая вопроса, а на «где мамонт?» уверенно показывает на валун.🦴

Ещё грань хаоса — контекст. Модели теряют нить рассуждений и подтягивают устаревшие паттерны: попросите её сгенерировать негативные проверки для формы регистрации — она может забыть про требования безопасности из другого документа.

Промпт сам по себе не типизирован, но современные API позволяют навязать схему через structured output или function calling. Вопрос не в том, можно ли типизировать взаимодействие с моделью, а в том, чтобы эта схема стала частью контракта и проверялась. 📜Иначе ошибки прячутся до момента выполнения и всплывают самым некрасивым образом — когда модель возвращает неожиданный формат и весь пайплайн падает каскадом ложных срабатываний. Или, по-пещерному, свод обваливается весь сразу🪨.

Отдельная симфония🎼 — несуществующие API. Модель уверенно предлагает вызвать метод, которого не существует: как будто она перепутала библиотеку, но забыла об этом упомянуть. Статическая типизация здесь безжалостна и потому полезна: компилятор не фантазирует, не додумывает и не «имеет в виду» — он просто говорит cannot find symbol. Самое честное код-ревью из доступных. Оговорка для честности: cannot find symbol ловит отсутствующий метод, но не ловит неверную логику, неверный контракт или семантически корректный, но бессмысленный JSON. Компилятор честен, но он не знает требований: он строгий вахтёр у входа — смотрит на пропуск, а не на лицо. Шаман лишь притворяется вахтёром.🚪