Как дробить задачу для ИИ: практика «1 экран/1 endpoint/1 правка», примеры формулировок, чеклисты и сигналы, когда пора остановиться.
Большой запрос к ИИ почти всегда заканчивается большим диффом. Модель пытается быть полезной сразу во всем: дописать экран, подтянуть данные, поправить валидацию, обновить структуру проекта и заодно "причесать" код. В итоге вы получаете не одну правку, а набор решений, которые сложно проверить одним взглядом, тот самый "коммит на тысячу строк".
Проблема не только в размере. Когда изменения расползаются, вы теряете контроль над границами задачи. ИИ не чувствует вашу "зону ответственности" так, как чувствует ее человек. Если вы не задали рамки, он будет заполнять пустоты догадками: менять стиль, переименовывать сущности, добавлять зависимости, править архитектуру.
В таких коммитах чаще всего страдают сразу несколько вещей. Логика упрощается и теряет крайние случаи, стиль превращается в смесь разных подходов, тесты перестают отражать реальное поведение. Часто всплывают проблемы с миграциями и данными (схемы меняются, а обратимый путь не продуман) и с безопасностью (лишние права, утечки логов, слабая валидация).
Есть и психологическая ловушка: "пусть ИИ сам разберется". Звучит удобно, но на практике означает, что вы заранее согласились на сюрпризы. А сюрпризы в коде стоят дорого: время уходит не на фичу, а на разбор последствий.
Дробление возвращает управление. Маленький шаг проще проверить, проще обсудить, проще откатить. Если вы работаете в TakProsto, можно дополнительно подстраховаться снапшотами и откатом: неудачную итерацию проще отменить, когда она не распухла до сотен строк.
Чтобы прогресс был предсказуемым, начинайте с жестких границ. Один небольшой шаг дает быстрый результат и позволяет рано заметить баг, пока он не спрятался внутри большого диффа.
Смысл правила простой: за одну итерацию просите у ИИ один заметный результат, который можно быстро проверить. Тогда вы контролируете изменения и не получаете коммит, где непонятно, что сломалось и почему.
"Один заметный результат" не равен "маленький файл" или "мало строк". Важны границы результата: что именно должно измениться для пользователя или для системы, и как вы поймете, что стало лучше.
POST /profile обновляет только телефон и возвращает обновленный профиль. Если внезапно добавились роли, загрузка фото и логирование, это уже не один endpoint.Формулируйте шаг так, чтобы проверка занимала минуты: открыть экран и увидеть изменение, вызвать один запрос и сравнить JSON, прогнать одну проверку.
Пример: вместо "сделай настройки уведомлений" попросите "на экране настроек добавить один переключатель Email-уведомления, сохранить его через один endpoint, без изменения остальных настроек". Такой шаг легко зафиксировать и откатить, если он оказался шире, чем вы планировали.
Когда запрос слишком широкий, ИИ почти неизбежно отвечает широкими изменениями. Начните с одного предложения: что именно должно измениться для пользователя или системы.
Сразу добавьте критерий "готово". Не "сделай авторизацию", а "пользователь видит форму входа и после успешного входа попадает на главную; при неверном пароле показываем сообщение об ошибке". У шага должен быть один результат, который можно проверить за пару минут.
Дальше выберите тип шага: один экран (UI), один endpoint (сервер) или одна правка (точечное изменение). Если вы не можете честно выбрать один тип, шаг еще слишком большой.
Перед тем как просить код, опишите входы и выходы простыми словами: какие данные приходят, какие состояния возможны, какие ошибки допустимы. Например, для кнопки "В избранное" входом будет ID товара и статус пользователя, а выходом - новый статус (в избранном или нет) и сообщение об ошибке, если пользователь не вошел.
И обязательно ограничьте область изменений: какие файлы трогаем, а какие нет. Это снижает риск "случайного ремонта" чужих частей проекта.
Перед выполнением попросите ИИ сначала короткий план шага и список файлов, которые он собирается менять. Можно прямо так:
Если вы работаете в TakProsto (часто это React на фронте и Go на бэкенде), такой запрос особенно полезен: он сразу задает границы, и вы быстрее получите проверяемый коммит вместо "переписали половину проекта".
Ниже три заготовки, которые помогают удерживать шаг маленьким и понятным. Их удобно вставлять в чат и заполнять квадратные скобки.
Тип: 1 экран (UI)
Контекст: [страница/экран], стек: [React/Flutter]
Цель: добавить/изменить ОДИН экран: [что именно]
Состояния экрана:
- загрузка: [что показываем]
- пусто: [когда пусто и какой текст/кнопка]
- ошибка: [какая ошибка и что может сделать пользователь]
Ограничения:
- не трогай другие экраны и роутинг
- максимум 1-2 файла, если возможно
Проверь себя:
- перечисли, что изменится в UI, и как это проверить вручную
Фраза-стоп:
- если нужно больше 30-50 строк, сначала предложи 2 альтернативы, как упростить шаг
Тип: 1 endpoint (API)
Контекст: бэкенд [Go], БД [PostgreSQL]
Нужно добавить ОДИН endpoint.
- Путь: [GET/POST] /api/[...]
- Назначение: [одним предложением]
- Запрос: поля и типы: [список]
- Ответ 200: поля и типы: [список]
- Ошибки: коды и условия: [400/401/404/409/500]
Границы:
- без новых таблиц/миграций (если не указано)
- без изменений в других endpoint
Попроси:
- минимальный дифф и краткое объяснение по каждому измененному файлу
- примеры 2-3 запросов/ответов
Фраза-стоп:
- если нужно больше 30-50 строк, сначала предложи альтернативы (упростить схему, отложить валидацию, вернуть меньше полей)
Тип: 1 правка (точечное изменение)
Что меняем: [конкретное поведение]
Где: [файл/папка/функция]
Почему: [баг/улучшение/логика]
Ожидаемый результат: [как должно работать]
Проверка: [шаги руками или простая проверка]
Требования к ответу:
- покажи минимальный дифф
- объясни, какие строки изменены и зачем
Фраза-стоп:
- если правка тянет больше 30-50 строк, остановись и предложи план из 2-3 маленьких шагов
Если модель начинает расширять область работ, возвращайте ее к рамкам простыми просьбами: "Поменяй только в указанном файле", "Не добавляй новые зависимости", "Сначала напиши план, потом код". Это почти всегда дешевле, чем разбирать большой неожиданный коммит.
Представим простую фичу: нужен экран со списком заявок и один endpoint, который отдает данные для этого списка. Если просить ИИ сделать все сразу, он почти наверняка полезет менять половину проекта: роутинг, модели, таблицы, UI-компоненты, обработку ошибок, а заодно "улучшит" то, что вы не просили.
Ниже пример разбиения по правилу "1 экран/1 endpoint/1 правка".
После каждой итерации должно быть четкое "работает вот это":
Если на проверку уходит дольше или вы не можете сказать, что именно стало лучше, шаг получился слишком большим. Остановитесь и попросите план следующего микрошагa, а не новый "коммит на тысячу строк".
Когда вы просите сделать маленький шаг, а в ответ получаете пачку правок по всему проекту, это почти всегда знак: граница шага потеряна. В практике "1 экран/1 endpoint/1 правка" важно вовремя остановиться, иначе проверка превращается в угадайку, а ошибки прячутся в мелочах.
Самые частые сигналы такие:
Простой пример: вы попросили добавить кнопку "Сохранить" на экране профиля. Если ИИ параллельно добавил новую таблицу, новый endpoint, поменял схему авторизации и "чуть-чуть" обновил дизайн, вы уже не знаете, проверять ли UI, миграции, права доступа или API-контракт. Граница шага должна быть такой, чтобы вы могли проверить результат за 5-10 минут.
Если заметили хотя бы 1-2 сигнала, остановитесь и попросите не код, а план следующего микрошагa: что меняем, какие файлы, какой критерий готовности, как проверить. В TakProsto это удобно фиксировать в planning mode, а реализацию запускать только после того, как рамки согласованы.
Если вы заметили, что ИИ уже правит "все подряд", самое полезное действие - остановить его прямо сейчас. Чем дальше вы идете, тем сложнее понять, где сломалось и что именно вы хотели получить.
Попросите зафиксировать текущую точку и вместо кода выдать план следующих 3-5 маленьких шагов. Такой план быстро показывает, что расползлось (UI, бэкенд, схема БД, тесты) и что реально нужно первым.
Чтобы вернуться к контролю, задайте границы изменений как короткий контракт. Например: "не трогай авторизацию", "не меняй структуру таблиц", "endpoint /api/orders оставь как есть", "никакого рефакторинга компонентов, которые не участвуют в задаче".
Полезно попросить перечислить риски и вопросы, которые надо уточнить до продолжения. Часто всплывает то, что вы не проговорили: формат дат, валидация, права доступа, обратная совместимость, миграции.
Если изменения уже слишком большие, не пытайтесь "долечить" их новыми правками. Проще откатиться (снапшот, rollback или обычный git) и повторить шаг меньшего размера.
Быстрый порядок действий, который обычно работает:
Пример: вы хотели добавить поле "Комментарий к заказу", а ИИ внезапно переписал форму, обновил несколько endpoint и начал "улучшать" модели. Остановите работу, зафиксируйте контракт ("меняем только форму и один endpoint"), откатитесь и попросите один конкретный кусок: добавить поле в UI и отправку в уже существующий запрос, без изменения схемы БД.
Чтобы маленький шаг оставался маленьким, проверяйте изменения по слоям. Это помогает не смешивать UI, API и БД в один коммит и быстрее находить причину поломки.
Сначала ответьте себе на вопрос: что именно должно было измениться в этом шаге? Один экран, один endpoint или одна правка - это не про размер кода, а про одну понятную пользу.
Перед коммитом пробегитесь по минимуму:
Теперь коротко прогоните ошибки, которые чаще всего всплывают у пользователей:
В конце оставьте "записку будущему себе" в 1-2 строки: какова была цель шага и как проверить результат вручную за минуту. Если получается больше, шаг, скорее всего, уже расползается.
Самая частая причина "коммита на тысячу строк" не в том, что ИИ ошибается, а в том, что ему дали слишком широкую цель. Начните с ловли типовых промахов и простых ограничений.
Когда в одном сообщении есть "сделай экран, добавь endpoint, накинь миграции, поправь дизайн и еще валидацию", модель честно пытается закрыть все сразу. Разделяйте по типу работы и по зоне кода. Часто лучший порядок такой: сначала один экран с мок-данными, потом один endpoint, потом миграция. Так проще проверить и откатить.
Если нет макета или явного "как выглядит готово", ИИ начинает угадывать: меняет отступы, цвета, названия компонентов, структуру. Вместо "красиво" дайте 2-3 проверяемых критерия: что должно появиться на экране, какие состояния нужны (загрузка, ошибка), какие тексты и где.
Набор привычек, который чаще всего спасает от расползания:
Пример: вы хотите добавить поле "Телефон" в форме профиля. Ошибка - просить сразу UI, API, базу и валидацию. Лучше: сначала добавить поле на экране и сохранить в локальном состоянии. После проверки - следующий шаг: отправка на существующий endpoint. И только потом, если нужно, миграция и изменение схемы.
Если вы делаете это в TakProsto, удобно держать итерации короткими: правка, быстрая проверка, снимок, и только потом следующий шаг.
У шага должен быть понятный результат, который можно увидеть или измерить. Не "улучшить профиль", а "на экране профиля появилась кнопка Сохранить и она блокируется при пустом имени". Не "сделать API", а "endpoint возвращает 200 и JSON с полями X и Y".
Хорошая проверка: можно ли подтвердить результат за 5-10 минут. Если на проверку нужно полчаса, вы почти наверняка попросили слишком много, и модель будет менять лишнее. Проверка может быть ручной (открыть один экран) или простой (один запрос к endpoint).
Правило на случай сомнений: если вы не уверены, что изменения безопасны, делайте шаг меньше. Представьте, что вам нужно откатить изменения. Если откат будет болезненным, шаг стоит разделить на два: сначала подготовка (минимальные правки), потом функционал.
Ритм, который помогает не улетать в "коммит на тысячу строк":
Пример: вы хотите "редактирование профиля". Маленький полезный шаг: добавить на экран одно поле "Имя" и локальную валидацию, без сохранения на сервер. Готово: поле видно, ошибка показывается, кнопка не активна при пустом значении. Следующим шагом будет один endpoint сохранения.
Чтобы не застрять в бесконечном дроблении, держите цель фичи перед глазами. Если шаг не приближает к ней напрямую, это не шаг, а отвлечение.
Чтобы правило "1 экран/1 endpoint/1 правка" работало каждый день, заведите простой ритуал перед каждым шагом.
Начинайте с короткого запроса к ИИ еще до кода: пусть назовет затронутые файлы, предложит стратегию диффа (что меняем и что не трогаем) и перечислит проверки. Так вы заранее видите границы и можете остановить шаг, если он расползается.
В TakProsto удобно сначала согласовать 3-6 маленьких шагов в planning mode, а генерацию кода делать только для первого. План нужен не для красоты, а чтобы у каждого шага был измеримый результат.
Перед выполнением шага зафиксируйте договоренности мини-чеклистом:
Дальше используйте снимки и откат. Сделайте snapshot перед генерацией, и еще один после, если шаг прошел проверки. Если ИИ неожиданно полез "заодно" править стили по всему проекту или переписывать API, откатывайтесь без сожалений и возвращайтесь к следующему микрошагу.
Если нужен внешний взгляд, в TakProsto есть экспорт исходников: так проще показать изменения коллеге или прогнать дополнительное ревью.
Следующий практический шаг: соберите план из 3-4 итераций и выполните первую "1 правку". Например, не "добавь регистрацию", а "на экране логина добавить поле и показать ошибку валидации, без изменения бэкенда". Если захотите попробовать это сразу в продукте, достаточно открыть takprosto.ai и начать с планирования одного шага, а не всей фичи целиком.
Потому что модель старается «закрыть» цель целиком и заполняет пробелы догадками: правит стиль, переименовывает сущности, меняет структуру и добавляет то, что кажется логичным. В итоге вы получаете набор решений, которые трудно проверить одним взглядом.
Сформулируйте один проверяемый результат: что конкретно изменится для пользователя или системы, и как вы это проверите за несколько минут. Если вы не можете описать проверку в одном-двух предложениях, шаг, скорее всего, слишком большой.
Выберите один тип: либо один экран (UI), либо один endpoint (API), либо одна точечная правка. Это не про количество строк, а про одну «единицу результата», которую можно быстро принять или откатить.
Начните с одного предложения «что меняется» и добавьте критерий готовности: что должно работать и какое сообщение или поведение будет при ошибке. Затем явно ограничьте область: какие файлы можно менять, а какие трогать нельзя, чтобы ИИ не занялся «случайным ремонтом».
Попросите сначала короткий план и список файлов, которые он собирается менять, а уже потом код. Это сразу показывает, расползается ли задача, и позволяет остановить работу до того, как появится «коммит на тысячу строк».
Явный сигнал — когда за один проход затрагиваются сразу UI, API и база, или появляются «заодно» правки вроде переименований, рефакторинга и новых абстракций. Если в ответе много предположений про устройство проекта и непонятно, что тестировать первым, остановитесь и верните шаг к четким границам.
Не пытайтесь «долечить» это следующими командами поверх. Зафиксируйте, что уже изменено, задайте жесткие запреты (например, не трогать авторизацию или структуру папок) и вернитесь к плану из нескольких микрошагов, чтобы снова стало понятно, что именно проверять.
Сделайте шаг меньше и сначала проверьте связку «экран — запрос — отображение» на мок-данных или фиксированном ответе, а подключение реальных данных отложите на следующую итерацию. Такой подход снижает риск сломать миграции, контракты и обработку ошибок одновременно.
Снапшот перед генерацией и откат после неудачной итерации экономят время, потому что вы не обязаны разбирать последствия большого диффа. Planning mode полезен, чтобы заранее согласовать 3–6 маленьких шагов и запускать генерацию только для первого, удерживая границы задачи.
Держите правило «не расширять область»: не добавлять новые зависимости, не менять структуру и не трогать соседние модули без прямого запроса. Если нужна проверка со стороны, используйте экспорт исходников, чтобы показать изменения коллеге или быстро провести ревью вне чата.