Почему я перестал сразу просить AI писать код

Есть очень естественная привычка, которая появляется почти у всех, кто начинает использовать AI в разработке.

Есть задача. Ты открываешь чат или coding agent. Пишешь:

Сделай X.

И через несколько секунд получаешь код.

Это впечатляет. Особенно в начале. Ты только сформулировал мысль, а инструмент уже создаёт классы, меняет зависимости, пишет тесты и иногда даже объясняет, что именно сделал.

На фоне обычной разработки это ощущается почти как перемотка времени вперёд.

Поэтому довольно долго мой процесс выглядел именно так:

Сделай X
    ↓
AI пишет код

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

Скорость оказалась довольно опасной

Когда код пишешь самостоятельно, между постановкой задачи и реализацией почти неизбежно существует пауза.

Нужно открыть проект. Найти нужное место. Прочитать несколько классов. Вспомнить, как здесь всё устроено. Посмотреть похожую реализацию. Иногда в процессе понимаешь, что первоначальная идея вообще не подходит.

Эта задержка кажется обычной частью работы. Но на самом деле она выполняет очень важную функцию. Она заставляет разобраться.

С AI эту паузу легко случайно убрать. Ты пишешь:

Добавь возможность повторно отправлять уведомление.

И инструмент почти сразу начинает менять проект. Через минуту у тебя уже появился controller. Service. Кнопка. Тест. Возможно, всё даже проходит CI.

И именно поэтому возникает ощущение, что задача почти решена. Хотя главный вопрос ещё даже не был задан:

А туда ли мы вообще пошли?

Я несколько раз получал хороший код, который мне не был нужен

Это, наверное, лучший способ описать проблему.

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

Например, я прошу:

Добавь фильтр по статусу заказа.

AI находит список заказов. Добавляет параметр в запрос. Меняет repository. Дописывает UI. Пишет тест. Вроде бы всё хорошо.

А потом выясняется, что в проекте уже есть отдельная система фильтров, которую использует несколько экранов. И теперь появляется ещё одна реализация того же поведения.

Ничего катастрофического. Но если бы AI сначала исследовал проект, этого кода вообще не понадобилось бы писать.

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

Раньше я считал генерацию началом работы

Теперь стараюсь считать её почти последним этапом. Моя привычная схема постепенно изменилась.

Было:

задача
    ↓
код
    ↓
смотрим, что получилось

Стало скорее так:

задача
    ↓
разберись
    ↓
расскажи, что нашёл
    ↓
предложи план
    ↓
обсудим
    ↓
только потом меняй код

На первый взгляд кажется, что я просто добавил несколько лишних шагов. Иногда именно так и есть. Для маленькой очевидной задачи эта церемония совершенно не нужна.

Но для изменений, которые затрагивают несколько частей проекта, разница огромная. Потому что теперь первая задача AI — не написать. Первая задача — понять.

«Сначала разберись»

Наверное, это одна из самых часто используемых мной инструкций сейчас. Она звучит почти слишком просто:

Сначала разберись, как это работает сейчас. Ничего не меняй.

И после неё работа становится заметно интереснее.

AI начинает искать. Открывает связанные классы. Смотрит вызовы. Находит тесты. Читает конфигурацию. Иногда обнаруживает комментарии или старые реализации. Иногда приходит к выводу, который совпадает с моим. Иногда нет.

Но главное — у нас появляется общая отправная точка. Пока AI сразу пишет код, я вижу только результат его рассуждений. Когда он сначала исследует, я могу проверить само понимание задачи. А это намного полезнее.

«Расскажи, что нашёл»

Следующий этап оказался для меня даже важнее исследования.

Недостаточно просто сказать AI:

Изучи проект.

Если после этого сразу разрешить писать код, часть проблемы остаётся. Я не знаю, что именно он понял.

Поэтому я всё чаще прошу сначала сделать небольшой отчёт. Например:

Опиши текущий flow.

Или:

Перечисли основные классы, которые участвуют в этой логике.

Или:

Расскажи, какие варианты изменения ты видишь и какие ограничения заметил.

Это очень простой checkpoint. Но он позволяет поймать ошибки до первой изменённой строки.

AI может сказать:

Статус заказа меняется только в OrderService.

А я знаю, что это не так. Есть ещё asynchronous handler. Значит, исследование неполное. Можно отправить его искать дальше. Без этого checkpoint он уже начал бы строить решение на ложном основании.

Оказалось, что обсуждать понимание дешевле, чем исправлять реализацию

Это довольно очевидная мысль. Но почему-то мне понадобилось несколько неудачных экспериментов, чтобы начать применять её последовательно.

Представим, что AI неправильно понял архитектуру. Если обнаружить это на этапе исследования, достаточно написать:

Ты пропустил ещё один сценарий. Посмотри обработчики очереди.

Если обнаружить это после реализации, нужно:

• понять, какие изменения построены на ошибочном предположении;
• удалить часть кода;
• переделать другую;
• обновить тесты;
• снова прогнать проверки.

Чем дальше неправильное предположение успевает пройти по цепочке, тем дороже его исправление.

То есть старый принцип разработки никуда не исчез. Ошибку в требованиях дешевле исправить до реализации. Просто теперь этот принцип приходится применять ещё и к AI.

«Предложи план»

После исследования я обычно не хочу сразу видеть код. Мне интересно, как AI собирается решать задачу.

Поэтому следующий запрос часто выглядит так:

Предложи план изменений. Пока ничего не меняй.

План может быть очень коротким. Не нужно превращать каждую задачу в RFC. Мне важно увидеть несколько вещей: какие части проекта он собирается менять; что хочет переиспользовать; где видит основную бизнес-логику; какие проверки собирается добавить; что считает потенциально рискованным.

Иногда уже на этом этапе становится понятно, что решение мне не нравится. И это прекрасно. Потому что пока нет кода, который нужно переделывать.

План нужен не только AI

Сначала я воспринимал этот этап как способ контролировать агента. Но довольно быстро обнаружилось, что он полезен и мне.

Когда AI пишет:

Я предлагаю изменить A, добавить B и переиспользовать C,

возникает возможность самому остановиться и подумать. А действительно ли нужен B? Почему я раньше считал, что надо менять D? Может быть, C действительно уже решает половину задачи?

То есть AI не просто показывает собственный план. Он создаёт точку, в которой я сам могу проверить первоначальное представление о задаче. Иногда в результате меняется решение AI. Иногда меняется моё.

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

Иногда я специально прошу несколько вариантов

Ещё одна привычка появилась чуть позже. Если задача не совсем очевидная, вместо:

Предложи план.

можно попросить:

Предложи два-три варианта и объясни компромиссы.

Это особенно полезно в тех местах, где есть архитектурный выбор. Можно добавить новое состояние в существующую сущность. Можно вынести отдельную сущность. Можно использовать событие. Можно расширить уже существующий механизм.

Когда сразу просишь реализацию, AI обычно выбирает один путь и начинает уверенно двигаться по нему. Когда сначала просишь варианты, становится видно само пространство решений. А обсуждать выбор между тремя абзацами гораздо удобнее, чем между тремя уже написанными реализациями.

«Только потом меняй код»

И вот только после этого начинается то, с чего раньше я начинал сразу.

Хорошо. Реализуй второй вариант.

На этом этапе AI уже знает проект немного лучше. Мы согласовали понимание задачи. Уточнили ограничения. Выбрали подход. И код становится не исследованием методом проб и ошибок, а реализацией уже обсуждённого решения.

Разумеется, это ничего не гарантирует. Ошибки всё равно возникают. Можно пропустить edge case. Можно неправильно понять бизнес-логику. Можно написать плохой тест. Можно сломать соседний сценарий.

Но характер ошибок становится другим. Мы хотя бы уменьшаем вероятность того, что вся реализация с самого начала построена на неверном основании.

Cursor хорошо попал в эту привычку

Позже подобное разделение стало всё заметнее появляться и в самих инструментах. У Cursor появились режимы, в которых можно отдельно попросить исследовать задачу, задать вопросы, составить план и только потом переходить к изменениям.

И мне это довольно хорошо легло на уже сформировавшуюся привычку. Но для меня важен порядок причин и следствий.

Я не начал сначала планировать потому, что в интерфейсе появилась соответствующая кнопка. Скорее наоборот. Я уже успел несколько раз столкнуться с тем, насколько полезно отделять исследование от реализации. А потом инструменты начали всё лучше поддерживать именно такую работу.

Поэтому я воспринимаю Plan или Ask modes не как отдельную feature редактора. Для меня они отражают более важную идею:

AI не обязательно должен отвечать кодом на каждый запрос разработчика.

Иногда лучший результат его работы — это хорошее понимание задачи.

Самая трудная привычка — не нажимать «реализовать» слишком рано

Потому что генерация кода даёт очень приятное ощущение прогресса. Файлы меняются. Появляются тесты. Diff растёт. Кажется, что работа идёт.

Исследование выглядит гораздо менее эффектно. AI читает код. Что-то ищет. Пишет несколько абзацев. Внешне почти ничего не произошло.

Но именно на этом этапе иногда экономится больше всего времени. Хороший найденный факт может сделать половину будущей реализации ненужной. Хороший вопрос может показать, что требования противоречат друг другу. Хороший план может обнаружить изменение публичного API до того, как оно появится в diff.

Это очень похоже на обычную разработку. Самая ценная работа далеко не всегда производит больше строк кода.

Я стал чаще запрещать AI писать код

Звучит немного смешно. Мы получили инструменты, главное впечатляющее свойство которых — способность писать код. И одна из самых полезных моих инструкций теперь:

Не пиши код.

Или:

Пока ничего не меняй.

Или:

Только исследование.

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

Конечно, я не делаю так с каждой задачей

Если нужно исправить очевидную опечатку, никакой research phase не нужен. Если я знаю точное место и точное изменение, можно просто сказать:

Поменяй это значение и запусти тест.

Если нужно написать небольшой изолированный helper, тоже нет смысла превращать работу в многоступенчатый процесс.

Я не хочу заменить старую крайность новой. Было бы странно раньше на каждую задачу сразу просить код, а теперь на каждую задачу требовать исследование, архитектурный документ и три варианта реализации.

Размер процесса должен соответствовать размеру неопределённости. Чем меньше я понимаю задачу заранее и чем шире потенциальные изменения, тем полезнее разделять этапы. Чем задача очевиднее, тем быстрее можно переходить к реализации.

Постепенно я начал видеть в этом обычный инженерный процесс

Интересно, что сама схема совсем не новая. Если убрать слово AI, получится знакомая последовательность:

исследование
    ↓
понимание проблемы
    ↓
варианты решения
    ↓
план
    ↓
реализация
    ↓
проверка

Хорошие разработчики и раньше так работали. Просто многие этапы происходили внутри головы и поэтому были практически невидимы.

Когда появляется AI, их приходится делать явными. Нельзя просто подумать про себя:

Ага, здесь лучше использовать существующий механизм событий.

Нужно либо дать агенту самому это обнаружить, либо передать ему этот контекст.

Получается любопытный эффект. AI не изобрёл новый инженерный процесс. Он заставил меня лучше увидеть существующий.

И теперь «написать код» для меня — не первый запрос

Сегодня, когда появляется новая задача, мне всё реже хочется сразу писать:

Реализуй.

Первый запрос чаще выглядит примерно так:

Разберись, как сейчас работает эта часть системы. Найди связанные компоненты, существующие ограничения и похожие реализации. Пока ничего не меняй.

Потом:

Кратко расскажи, что нашёл.

Потом:

Предложи план.

И только когда понимание задачи выглядит достаточно похожим на реальность:

Теперь реализуй.

Это не такой эффектный процесс. AI не начинает мгновенно печатать сотни строк. Иногда несколько первых итераций вообще не изменяют проект. Зато всё чаще я замечаю, что именно эти итерации и являются самой важной частью работы.

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

И сейчас мне кажется, что именно ей я в основном и учусь. К этому я пришёл и в первом эксперименте, когда отдал задачу целиком: реализация без исследования легко решает не ту проблему.