Как сделать написание AI-кода более предсказуемым и контролируемым

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

Гит - ваш лучший друг
Базовый совет, которым многие принебрегают. Сохраняйте весомые изменения. ВСЕГДА. Сделали фичу - залейте в гит. Потратите 30 секунд времени, но избавите себя от головной боли с откатом изменений.

Откажитесь от автономных мультиагентных систем
Я писал об этом ранее. Как бы соблазнительно ни звучала идея того, что AI за вас и ТЗ напишет и тесты - на данный момент этот подход я называю “наговнякать и оно как-то работает”. Помимо того, что это дорого и чревато каскаднымы галлюцинациями, есть куча других “бонусов”. Вы не будете знать архитектуру, вы не будете понимать, какой файл и за что у вас отвечает, вы не будете знать, что грузить в контекст LLM, а что нет. В конечном итоге вы утратите контроль над процессом

ТЗ - всему голова
Уделите особое внимание написанию ТЗ. По моему опыту - это ~70% вашего результата. Не нужно уходить в технические дебри. Опишите подробные сценарии, как бы вы сделали для человека. Само ТЗ разбейте на этапы с точки зрения User Stories, чтобы их можно было потестить. При работе просите агента изолированно реализовать каждую функцию, дайте ему общий контекст о том, что вы делаете, а затем - только описание нужной вам фичи.

Одно изменение за раз
Старайтесь избегать ситуаций в стиле “Увеличь мне кнопку, добавь картинку, а еще сделай мобильный адаптив”. Это три разные задачи, причем третья может быть вообще огромной. Можно объединять в одной задаче “изменения” - типа изменения вида и положения элементов. “Добавления” и “Создания с нуля” - лучше всегда выносить отдельно.

Отключите лишние MCP
Они засоряют контекст. В результате вы сталкиваетесь с тем, что модель что-то упускает, либо делает то, что вы ее не просили. Не работаете с фигмой? Выключите Figma MCP. Скармливаете модели документацию вручную? Отключите Context 7, он вам не нужен, и так далее.

Смоук-тесты - ваша опора
Хорошей практикой будет писать тесты. Тесты мы просим LLM писать с опорой на ТЗ. При каждом изменении перед публикацией в Гит - прогоняем тесты. С написанием тестов лучше справляются консервативные модели, вроде GPT o3 и GPT-5.

Вникайте в код
Даже если вы не технарь. Читайте, что AI вам пишет. Просите объяснить, как и что работает, почему сделано методом А, а не методом B. На дистанции вы начнете замечать определенные патерны и сможете избегать типовых ошибок.

Не пытайтесь “ваншотить”
Сделать что-то с “одного промпта” - звучит классно, но на деле получается так себе. Базовый минимум - спросить сначала агента, КАК и ЧТО он будет делать, а только потом приступить к реализации на основании этого плана. Вам - больше контроля, а AI - больше системности.

Выносите сложные куски в другие AI и понижайте температуру
Не работайте испключительно в Cursor, Claude Code или где-либо еще. Сложные фичи я рекомендую пробовать реализовать в той же AI Studio. Где вам нужен четкий результат - скрутите температуру в 0. Чаще всего это будет работать.

А какие у вас лайфхаки по работе с кодом?