Иногда я прошу ИИ улучшить производительность страницы и получаю на вид хороший результат: компонент становится проще, лишний код исчезает, рендеров становится меньше. Позже выясняется другое: страница тормозила из-за тяжёлого запроса, большого списка или лишней загрузки данных.
Так часто бывает с производительностью. Видно медленный участок интерфейса, и рука тянется к самому заметному месту:
Оптимизируй этот компонент.
Компонент рядом с проблемой, его легко открыть и переписать. Модель сделает это без лишних вопросов. Только причина может жить в другом месте: запросе к API, размере ответа, пагинации, кэше, изображениях, состоянии приложения или логике загрузки.
Ошибка возникает до кода: мы выбрали объект оптимизации раньше, чем разобрали, где страница реально теряет время.
Ложная определённость
Я называю это ложной определённостью.
Задача выглядит точной: есть действие, файл и ожидаемый результат. Но эта точность живёт внутри команды, а ситуация требует другой рамки. Команда может быть понятной, а выбранная рамка - слабой.
Есть задачи, где короткая инструкция как раз подходит:
Исправь опечатку в заголовке кнопки и проверь, что текст помещается в интерфейсе.
Здесь место известно, действие понятно, проверка простая. Большой анализ только замедлит работу.
В реальной разработке часто встречается другой тип задач. Мы видим симптом или желаемый результат, а карта затронутых частей ещё туманная:
после обновления сломалась авторизация;
релиз нужно сделать безопаснее;
страница стала медленно открываться;
большой модуль пора привести в порядок;
команда хочет добавить проверку качества, а место этой проверки ещё только предстоит выбрать.
Если сразу выбрать один коридор, ИИ пойдёт по нему уверенно. Ответ может быть грамотным и технически аккуратным. Польза при этом останется случайной.
Начать с рамки
Для неопределённых задач я начинаю с открытой рамки: сначала прошу разобрать место решения, а уже затем переходить к первой правке.
Страница каталога стала медленно открываться.
Разбери, где искать причину: компонент, запрос к API, размер ответа,
пагинация, изображения, кэш или состояние приложения.
Сначала покажи варианты, риски и критерий готовности.
К изменениям переходи после выбора подхода.
Такой запрос удерживает модель в рабочем коридоре. У него есть цель, границы и следующий шаг. Место правки пока остаётся вопросом, который нужно решить перед изменениями.
В хорошем открытом запросе обычно есть пять частей:
что произошло;
какой результат нужен;
что пока неизвестно;
по каким критериям выбирать решение;
когда переходить к изменениям.
Эта постановка помогает модели сделать полезную работу до редактирования кода или документации: найти варианты, показать риски, назвать первый безопасный шаг.
Три режима постановки задачи
Я делю рабочие запросы к ИИ на три режима.
1. Известно действие
Подходит короткая команда:
Исправь опечатку в заголовке кнопки.
Проверь, что текст помещается в интерфейсе.
Рамка ясна, место известно, критерий проверки рядом.
2. Известен результат
Здесь лучше описать цель и критерии, оставив модели выбор пути:
Нужно сделать обновление приложения безопаснее для пользователей.
Сравни варианты: проверки перед релизом, rollback, changelog, инструкцию
обновления и smoke-тесты.
Для каждого варианта назови пользу, риск и минимальный объём.
Такой запрос задаёт направление и оставляет путь открытым для выбора.
3. Непонятна система связей
Тут работа начинается с диагностики:
После обновления у части пользователей сломалась авторизация.
Проверь возможные зоны: API, frontend, cookies, настройки домена и миграции.
Предложи порядок проверки и ближайший безопасный шаг.
К исправлению переходи после подтверждения причины.
В этом режиме ИИ помогает искать границы задачи. Инженерная проверка остаётся обязательной, а модель ускоряет разбор связей.
Чем здесь полезны генеративные модели
Генеративная модель умеет выполнять инструкции, но в таких задачах особенно полезна другая способность: разложить симптом на гипотезы и предложить порядок движения.
Если стартовать с рамки, ИИ может:
найти затронутые части проекта;
отделить симптом от причины;
предложить несколько путей;
выделить первый обратимый шаг;
назвать проверки;
заметить блокеры;
вынести лишние идеи в отдельные задачи;
превратить локальную правку в повторяемое правило.
Но этот режим полезен только на старте. После анализа рамку нужно закрывать.
Закрыть рамку
У генеративной модели есть другая крайность: она всегда может предложить ещё один вариант, риск, проверку или рефакторинг. Для поиска это полезно. Для завершения работы - опасно.
После анализа я перевожу задачу в режим закрытия через критерий готовности: по нему понятно, что работу можно считать законченной.
Полезные формулировки:
Сформулируй критерий готовности.
Что должно быть сделано, чтобы задачу можно было закрыть?
Раздели обязательное для закрытия задачи и улучшения на потом.
Держи текущий объём задачи.
Доведи текущий результат до критерия готовности.
Новые идеи вынеси в отдельные задачи.
Проверь готовность результата.
Если работа ещё открыта, назови только ближайшие блокеры.
После этого модель меньше расползается в стороны и начинает помогать закрывать работу с проверяемым результатом.
Рабочий цикл
Для задач с неопределённой рамкой у меня получается такой порядок:
открытая рамка
-> анализ связей
-> цель и критерий готовности
-> план
-> подтверждение
-> выполнение
-> проверка
-> вопрос "готово ли?"
-> закрытие или точечный следующий шаг
Открытая рамка нужна до реализации, когда место решения ещё ищется. Критерий готовности нужен после анализа, чтобы работа дошла до проверяемого конца.
Если оставить только открытые вопросы, задача расползётся. Если оставить только команды, можно быстро получить аккуратную правку слабого решения. Сильный результат обычно находится между этими режимами: сначала найти рамку, потом довести её до готового результата.
Примеры
Медленная страница
Слабый старт:
Оптимизируй этот компонент.
Лучше:
Страница каталога стала медленно открываться.
Разбери, где искать причину: компонент, запрос к API, размер ответа,
пагинация, изображения, кэш или состояние приложения.
Сначала предложи варианты, риски и критерий готовности.
К изменениям переходи после выбора подхода.
Баг-репорт
Слабый старт:
Почини баг.
Лучше:
Разбери баг-репорт.
Сначала воспроизведи проблему, выдели вероятные причины, предложи минимальный
план исправления и критерий повторной проверки.
Держи объём работы в границах закрытия бага.
Большой рефакторинг
Слабый старт:
Отрефактори модуль.
Лучше:
Оцени, какой минимальный безопасный объём рефакторинга даст пользу.
Раздели обязательное, рискованное и необязательное.
Сначала предложи критерий готовности и первый обратимый шаг.
Подготовка релиза
Слабый старт:
Сделай релиз.
Лучше:
Проверь готовность к релизу.
Собери объём изменений, блокеры, changelog, проверки, rollback и инструкцию
обновления. При готовности предложи план выпуска. При блокерах назови только
то, что мешает релизу.
Короткая памятка
Если известно точное действие:
Сделай X в Y, проверь Z.
Если известен результат:
Нужно получить X. Выбери безопасный путь и объясни критерии.
Если система связей ещё туманная:
Сначала определи затронутые части, варианты, риски и ближайший безопасный шаг.
Если задача начинает разрастаться:
Сформулируй критерий готовности.
Что осталось до закрытия задачи?
Новые идеи вынеси в отдельные задачи.
Если работа большая:
Сформулируй цель, этапы, критерий готовности и ближайшие шаги.
После моего подтверждения выполняй до готового результата или реального
блокера.
Вывод
Точный запрос к ИИ хорош после выбора рамки. До этого точность может увести работу в сторону: модель аккуратно выполнит команду, а задача останется в старом состоянии.
Сначала стоит понять, где находится решение. Потом выбрать критерий готовности. И только после этого просить модель выполнять конкретные изменения.
Так ИИ работает как инструмент для поиска правильной рамки и доведения работы до проверяемого результата.