Как дробить задачу для ИИ: 1 экран, 1 endpoint, 1 правка

Почему большие задачи дают слишком большие изменения

Большой запрос к ИИ почти всегда заканчивается большим диффом. Модель пытается быть полезной сразу во всем: дописать экран, подтянуть данные, поправить валидацию, обновить структуру проекта и заодно "причесать" код. В итоге вы получаете не одну правку, а набор решений, которые сложно проверить одним взглядом, тот самый "коммит на тысячу строк".

Проблема не только в размере. Когда изменения расползаются, вы теряете контроль над границами задачи. ИИ не чувствует вашу "зону ответственности" так, как чувствует ее человек. Если вы не задали рамки, он будет заполнять пустоты догадками: менять стиль, переименовывать сущности, добавлять зависимости, править архитектуру.

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

Есть и психологическая ловушка: "пусть ИИ сам разберется". Звучит удобно, но на практике означает, что вы заранее согласились на сюрпризы. А сюрпризы в коде стоят дорого: время уходит не на фичу, а на разбор последствий.

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

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

Правило "1 экран/1 endpoint/1 правка" простыми словами

Смысл правила простой: за одну итерацию просите у ИИ один заметный результат, который можно быстро проверить. Тогда вы контролируете изменения и не получаете коммит, где непонятно, что сломалось и почему.

"Один заметный результат" не равен "маленький файл" или "мало строк". Важны границы результата: что именно должно измениться для пользователя или для системы, и как вы поймете, что стало лучше.

Что значит каждый пункт

• 1 экран: одна страница или один видимый сценарий. Например: "экран профиля: показать имя и телефон, добавить кнопку Сохранить". Не "весь кабинет" и не "вся авторизация".
• 1 endpoint: один маршрут API с понятным контрактом: входные поля, ответ, коды ошибок. Например, POST /profile обновляет только телефон и возвращает обновленный профиль. Если внезапно добавились роли, загрузка фото и логирование, это уже не один endpoint.
• 1 правка: одно точечное изменение в существующем коде. Например: "добавь обязательную валидацию email" или "добавь новое поле в таблицу и прокинь его в ответ". Не "перепиши архитектуру".

Формулируйте шаг так, чтобы проверка занимала минуты: открыть экран и увидеть изменение, вызвать один запрос и сравнить JSON, прогнать одну проверку.

Пример: вместо "сделай настройки уведомлений" попросите "на экране настроек добавить один переключатель Email-уведомления, сохранить его через один endpoint, без изменения остальных настроек". Такой шаг легко зафиксировать и откатить, если он оказался шире, чем вы планировали.

Как превратить "хочу фичу" в один маленький шаг

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

Сразу добавьте критерий "готово". Не "сделай авторизацию", а "пользователь видит форму входа и после успешного входа попадает на главную; при неверном пароле показываем сообщение об ошибке". У шага должен быть один результат, который можно проверить за пару минут.

Дальше выберите тип шага: один экран (UI), один endpoint (сервер) или одна правка (точечное изменение). Если вы не можете честно выбрать один тип, шаг еще слишком большой.

Перед тем как просить код, опишите входы и выходы простыми словами: какие данные приходят, какие состояния возможны, какие ошибки допустимы. Например, для кнопки "В избранное" входом будет ID товара и статус пользователя, а выходом - новый статус (в избранном или нет) и сообщение об ошибке, если пользователь не вошел.

И обязательно ограничьте область изменений: какие файлы трогаем, а какие нет. Это снижает риск "случайного ремонта" чужих частей проекта.

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

• Цель шага и "готово" в 1-2 строках
• Тип шага: экран, endpoint или правка
• Входы/выходы и ошибки
• Какие файлы можно менять, какие нельзя
• План из 3-5 действий + список затрагиваемых файлов

Если вы работаете в 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 маленьких шагов

Если модель начинает расширять область работ, возвращайте ее к рамкам простыми просьбами: "Поменяй только в указанном файле", "Не добавляй новые зависимости", "Сначала напиши план, потом код". Это почти всегда дешевле, чем разбирать большой неожиданный коммит.

Пример: маленькая фича, разбитая на 3-4 итерации

Представим простую фичу: нужен экран со списком заявок и один endpoint, который отдает данные для этого списка. Если просить ИИ сделать все сразу, он почти наверняка полезет менять половину проекта: роутинг, модели, таблицы, UI-компоненты, обработку ошибок, а заодно "улучшит" то, что вы не просили.

Ниже пример разбиения по правилу "1 экран/1 endpoint/1 правка".

Итерации

• Итерация 1: делаем только чтение, без базы. Endpoint возвращает фиксированный JSON (2-3 элемента), чтобы проверить разметку и связку "экран - запрос - отображение". UI максимально простой: заголовок и список.
• Итерация 2: подключаем базу (например, PostgreSQL) и добавляем пагинацию на уровне endpoint. UI-логика почти не меняется, вы просто подсовываете реальные данные вместо моков.
• Итерация 3: доводим экран до "живого" состояния. Добавляем лоадер, пустое состояние и понятные сообщения об ошибке. Endpoint не трогаем, кроме мелких правок формата ошибок.
• Итерация 4 (если нужна): одна полировка без расширения объема, например сортировка по дате или фильтр по одному полю. Это отдельный маленький шаг, а не "заодно добавь все фильтры".

Как фиксировать результат каждого шага

После каждой итерации должно быть четкое "работает вот это":

• Какой один endpoint существует и какой у него контракт (пример ответа и параметры).
• Что видно на экране при успехе.
• Что видно при загрузке и при ошибке.
• Как проверить вручную за 1-2 минуты.

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

Сигналы, что задача расползается и пора остановиться

Когда вы просите сделать маленький шаг, а в ответ получаете пачку правок по всему проекту, это почти всегда знак: граница шага потеряна. В практике "1 экран/1 endpoint/1 правка" важно вовремя остановиться, иначе проверка превращается в угадайку, а ошибки прячутся в мелочах.

Самые частые сигналы такие:

• За один проход затронуты сразу несколько слоев: UI, API, база, авторизация. Даже если каждое изменение "логичное", вместе они плохо проверяются.
• ИИ начинает делать "заодно": наводит стиль, меняет структуру папок, правит линтер, переименовывает файлы.
• Появляются новые сущности, которых вы не просили: роли, таблицы, сервисы, "универсальные" абстракции.
• В ответе много допущений: "я решил, что вам нужно", "скорее всего у вас так устроено".
• Падает уверенность в проверке: неясно, что тестировать первым и что считать ожидаемым результатом.

Простой пример: вы попросили добавить кнопку "Сохранить" на экране профиля. Если ИИ параллельно добавил новую таблицу, новый endpoint, поменял схему авторизации и "чуть-чуть" обновил дизайн, вы уже не знаете, проверять ли UI, миграции, права доступа или API-контракт. Граница шага должна быть такой, чтобы вы могли проверить результат за 5-10 минут.

Если заметили хотя бы 1-2 сигнала, остановитесь и попросите не код, а план следующего микрошагa: что меняем, какие файлы, какой критерий готовности, как проверить. В TakProsto это удобно фиксировать в planning mode, а реализацию запускать только после того, как рамки согласованы.

Что делать, когда стало слишком много изменений

Если вы заметили, что ИИ уже правит "все подряд", самое полезное действие - остановить его прямо сейчас. Чем дальше вы идете, тем сложнее понять, где сломалось и что именно вы хотели получить.

Попросите зафиксировать текущую точку и вместо кода выдать план следующих 3-5 маленьких шагов. Такой план быстро показывает, что расползлось (UI, бэкенд, схема БД, тесты) и что реально нужно первым.

Чтобы вернуться к контролю, задайте границы изменений как короткий контракт. Например: "не трогай авторизацию", "не меняй структуру таблиц", "endpoint /api/orders оставь как есть", "никакого рефакторинга компонентов, которые не участвуют в задаче".

Полезно попросить перечислить риски и вопросы, которые надо уточнить до продолжения. Часто всплывает то, что вы не проговорили: формат дат, валидация, права доступа, обратная совместимость, миграции.

Если изменения уже слишком большие, не пытайтесь "долечить" их новыми правками. Проще откатиться (снапшот, rollback или обычный git) и повторить шаг меньшего размера.

Быстрый порядок действий, который обычно работает:

• Остановись и опиши, что уже изменено в 5-10 пунктах.
• Дай план 3-5 следующих шагов, каждый в стиле "1 экран/1 endpoint/1 правка".
• Перечисли риски и что нужно уточнить до кода.
• Прими границы изменений: что строго не менять.
• Если не помещается в шаг, откатываемся и начинаем заново меньшим кусочком.

Пример: вы хотели добавить поле "Комментарий к заказу", а ИИ внезапно переписал форму, обновил несколько endpoint и начал "улучшать" модели. Остановите работу, зафиксируйте контракт ("меняем только форму и один endpoint"), откатитесь и попросите один конкретный кусок: добавить поле в UI и отправку в уже существующий запрос, без изменения схемы БД.

Быстрый чеклист контроля качества маленького шага

Чтобы маленький шаг оставался маленьким, проверяйте изменения по слоям. Это помогает не смешивать UI, API и БД в один коммит и быстрее находить причину поломки.

Сначала ответьте себе на вопрос: что именно должно было измениться в этом шаге? Один экран, один endpoint или одна правка - это не про размер кода, а про одну понятную пользу.

Перед коммитом пробегитесь по минимуму:

• Одной фразой: что сделано и для кого (без деталей реализации).
• Список файлов: все ли изменения относятся к одному шагу, нет ли "заодно".
• Отдельно: что поменялось в UI, что в API, что в БД (или честно: "БД не трогали").
• Контракты: имена полей, типы, обязательность, коды ответов.
• Откат: есть ли быстрый способ вернуться назад и понимаете ли вы, что именно откатится.

Теперь коротко прогоните ошибки, которые чаще всего всплывают у пользователей:

• Пустой ответ: что видит UI, если данных нет.
• Неверный ввод: понятное сообщение, без падения.
• 401/403: что происходит без прав или без авторизации.
• 500: не раскрываем внутренности, но логируем и показываем нейтральный текст.
• Несовпадение формата: UI не должен ломаться, если поле отсутствует или пришло null.

В конце оставьте "записку будущему себе" в 1-2 строки: какова была цель шага и как проверить результат вручную за минуту. Если получается больше, шаг, скорее всего, уже расползается.

Частые ошибки и как их избегать

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

Ошибка 1: несколько целей в одном запросе

Когда в одном сообщении есть "сделай экран, добавь endpoint, накинь миграции, поправь дизайн и еще валидацию", модель честно пытается закрыть все сразу. Разделяйте по типу работы и по зоне кода. Часто лучший порядок такой: сначала один экран с мок-данными, потом один endpoint, потом миграция. Так проще проверить и откатить.

Ошибка 2: "сделай красиво" без критериев

Если нет макета или явного "как выглядит готово", ИИ начинает угадывать: меняет отступы, цвета, названия компонентов, структуру. Вместо "красиво" дайте 2-3 проверяемых критерия: что должно появиться на экране, какие состояния нужны (загрузка, ошибка), какие тексты и где.

Набор привычек, который чаще всего спасает от расползания:

• Запрещайте расширение объема: "меняй только файл X, без рефакторинга и переименований".
• Ограничивайте архитектуру: "не трогай структуру папок и общие модули, только этот компонент".
• Просите объяснение: "опиши, что изменил и зачем, и где проверить руками".
• Просите точки контроля: "какие 3 проверки я должен сделать после правки".
• Фиксируйте следующий шаг: "после этого шага предложи один следующий маленький шаг".

Пример: вы хотите добавить поле "Телефон" в форме профиля. Ошибка - просить сразу UI, API, базу и валидацию. Лучше: сначала добавить поле на экране и сохранить в локальном состоянии. После проверки - следующий шаг: отправка на существующий endpoint. И только потом, если нужно, миграция и изменение схемы.

Если вы делаете это в TakProsto, удобно держать итерации короткими: правка, быстрая проверка, снимок, и только потом следующий шаг.

Как понять, что шаг достаточно маленький и полезный

У шага должен быть понятный результат, который можно увидеть или измерить. Не "улучшить профиль", а "на экране профиля появилась кнопка Сохранить и она блокируется при пустом имени". Не "сделать API", а "endpoint возвращает 200 и JSON с полями X и Y".

Хорошая проверка: можно ли подтвердить результат за 5-10 минут. Если на проверку нужно полчаса, вы почти наверняка попросили слишком много, и модель будет менять лишнее. Проверка может быть ручной (открыть один экран) или простой (один запрос к endpoint).

Правило на случай сомнений: если вы не уверены, что изменения безопасны, делайте шаг меньше. Представьте, что вам нужно откатить изменения. Если откат будет болезненным, шаг стоит разделить на два: сначала подготовка (минимальные правки), потом функционал.

Ритм, который помогает не улетать в "коммит на тысячу строк":

• План на 3 маленьких шага (без деталей реализации)
• Выполнение только первого шага
• Быстрая проверка результата
• Решение: идем дальше или просим план следующего шага

Пример: вы хотите "редактирование профиля". Маленький полезный шаг: добавить на экран одно поле "Имя" и локальную валидацию, без сохранения на сервер. Готово: поле видно, ошибка показывается, кнопка не активна при пустом значении. Следующим шагом будет один endpoint сохранения.

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

Следующие шаги: как выстроить процесс в TakProsto

Чтобы правило "1 экран/1 endpoint/1 правка" работало каждый день, заведите простой ритуал перед каждым шагом.

Начинайте с короткого запроса к ИИ еще до кода: пусть назовет затронутые файлы, предложит стратегию диффа (что меняем и что не трогаем) и перечислит проверки. Так вы заранее видите границы и можете остановить шаг, если он расползается.

В TakProsto удобно сначала согласовать 3-6 маленьких шагов в planning mode, а генерацию кода делать только для первого. План нужен не для красоты, а чтобы у каждого шага был измеримый результат.

Перед выполнением шага зафиксируйте договоренности мини-чеклистом:

• Какие файлы можно менять и какие нельзя
• Какой результат считаем готовым (1 конкретная проверка)
• Что должно остаться без изменений (поведение, маршруты, таблицы)
• Как откатываемся, если изменений стало слишком много

Дальше используйте снимки и откат. Сделайте snapshot перед генерацией, и еще один после, если шаг прошел проверки. Если ИИ неожиданно полез "заодно" править стили по всему проекту или переписывать API, откатывайтесь без сожалений и возвращайтесь к следующему микрошагу.

Если нужен внешний взгляд, в TakProsto есть экспорт исходников: так проще показать изменения коллеге или прогнать дополнительное ревью.

Следующий практический шаг: соберите план из 3-4 итераций и выполните первую "1 правку". Например, не "добавь регистрацию", а "на экране логина добавить поле и показать ошибку валидации, без изменения бэкенда". Если захотите попробовать это сразу в продукте, достаточно открыть takprosto.ai и начать с планирования одного шага, а не всей фичи целиком.