Не меняйте шаблон подсказки для безопасных, маленьких итераций

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

«Небольшое» изменение редко остаётся маленьким. Вы просите подправить подпись кнопки, и вдруг сдвигается вёрстка страницы, форма перестаёт валидироваться или шаг оплаты ведёт себя иначе. Приложения — это связанные системы. UI, логика, данные и интеграции опираются друг на друга.

Частая причина — неясные границы. Если в запросе пишут «сделать регистрацию проще», исполнителю (человеку или ИИ) придётся догадываться, что значит «проще». Догадки ведут к дополнительным правкам: удалению полей, изменению шагов, корректировке копии или переписыванию валидации. Ещё одна причина — скрытые зависимости. Небольшое изменение UI может затронуть компонент, который используется на пяти других экранах.

Безопасная итерация значит: вы получаете одно ожидаемое улучшение, а всё остальное остаётся практически идентичным. Для нетехнической команды это означает, что рабочий процесс по-прежнему воспринимается пользователями одинаково, скрипты поддержки всё ещё соответствуют продукту, а отчётность не нарушена. Для технической команды это значит отсутствие неожиданных изменений маршрутов, формата данных, контрактов API или поведения в пограничных случаях.

Чтобы это стало возможным, нужно заморозить то, что нельзя менять. На практике это обычно включает критические потоки (точные шаги пользователей), детали UI/UX (вёрстка, отступы, поведение взаимодействия), бизнес-правила (ценообразование, права, валидация), поведение данных (что и когда сохраняется) и интеграции (события аналитики, письма, платежи, внешние API).

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

Что такое шаблон «не менять»

Шаблон «не менять» — простой способ попросить одно конкретное обновление, при этом явно зафиксировав всё остальное. Вы называете одно изменение, которое нужно внести, затем пишете короткий список заморозки частей, которые должны остаться идентичными после правки.

Это важно, потому что модели часто «стараются помочь», рефакторя, переименовывая, перестраивая файлы или «очищая» логику при внесении правок. Даже если результат по-прежнему работает, такие дополнительные изменения могут ввести баги, поменять поведение или усложнить ревью.

Сравните два запроса:

«Сделайте страницу настроек лучше.» Это приглашает дизайнерские изменения, новую копию, сдвиги в вёрстке и правки логики.

«Измените только текст метки с 'Phone' на 'Mobile phone'. Не меняйте вёрстку, валидацию или поведение сохранения.» Это узко, проверяемо и безопаснее.

Хороший список заморозки обычно охватывает три области:

• Потоки (user journeys): шаги, которые проходят пользователи, и какие экраны показываются.
• UI и UX детали: вёрстка, отступы, порядок полей, расположение кнопок и взаимодействия.
• Бизнес-правила и поведение данных: правила валидации, расчёты цен, права доступа, записи в БД и ответы API.

Когда вы используете этот шаблон в инструменте на основе чата вроде Koder.ai, итерации идут быстрее, потому что модель фокусируется на одном изменении, а не делает массовые «улучшения» без запроса.

Базовый шаблон, который можно переиспользовать

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

Скопируйте этот шаблон и заполните скобки. Держите его коротким, но конкретным.

Goal (one sentence):
- Change: [describe the one small change you want]

Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]

DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]

Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines

Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]

Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing

Конкретный пример: если вы хотите поменять цвет кнопки оформления заказа, ваша цель — «Обновить основной цвет кнопки оформления на #1A73E8.» В DO NOT CHANGE вы должны заморозить полный поток оформления, текст кнопки и расчёт цены.

Если вы используете Koder.ai, такой формат ускоряет ревью: вы можете сравнить acceptance checks с превью и сводкой изменений перед подтверждением.

Как заморозить критические потоки, не будучи расплывчатым

Когда вы просите небольшое изменение, не говорите просто «ничего не ломайте». Назовите точные пользовательские сценарии, которые должны работать одинаково, от первого клика до финального результата. Вы не замораживаете всё приложение, вы замораживаете те части, где регрессии вредят.

Начните с перечисления критических потоков простым языком: вход (включая сброс пароля), онбординг, checkout, настройки. Для каждого потока укажите, как выглядит «готово». Пример: «Пользователь может войти по email + паролю, попадает на Dashboard и остаётся залогинен после обновления страницы.»

Затем зафиксируйте пограничные случаи, которые часто забывают. Поведение кнопки «назад» — классический источник дрейфа: «Назад из Checkout возвращает в Cart (не на Home), и элементы в корзине сохраняются.» Обозначьте состояния ошибок («неверный пароль показывает то же сообщение»), пустые состояния («нет проектов показывает ту же копию пустого экрана») и загрузки («спиннер появляется в течение 200ms, без сдвигов вёрстки»).

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

Короткий способ это задать без длинного специфа:

• Потоки для заморозки: Login, Signup, Checkout, Settings (без новых шагов, без перестановки экранов)
• Пограничные случаи: поведение кнопки назад, сообщения об ошибках, пустые состояния, поведение при обновлении
• Данные для заморозки: что сохраняется, когда сохраняется и где отображается после перезагрузки
• Безопасность для заморозки: права доступа, проверки аутентификации, ограничения по частоте, без новых публичных эндпоинтов
• Производительность для заморозки: никаких дополнительных вызовов API в этих потоках, время отклика не хуже текущего

Будьте конкретны по потокам данных в одном предложении на пункт. Например: «Адрес сохраняется только после нажатия Save, хранится в записи профиля пользователя и должен сохраняться после выхода/повторного входа.» Такой уровень детализации предотвращает автосейв, новые поля или изменения тайминга, которые ломают реальных пользователей.

Как заморозить UI и UX детали

Дрейф UI обычно происходит потому, что модель «помогает», очищая стили, отступы или структуру компонентов. Решение такое же, как для бизнес-логики: назовите, что должно оставаться идентичным, и укажите одну вещь, которую можно менять.

Закрепите видимую структуру. Укажите вёрстку (колонки/строки, расположение шапки и подвала), правила отступов (padding, gaps, выравнивание) и поведение компонентов (hover, disabled, спиннеры, сообщения об ошибках). Если компонент имеет специфическое ощущение, скажите это прямо: «Размер кнопки, радиус и цвет должны оставаться точь-в-точь такие же.»

Адаптивность требует явных правил. Если не упомянуть мобильную версию, инструменты могут «улучшить» её. Укажите брейкпоинты и поведение для каждого: порядок стэкинга, скрытые элементы, фиксированные панели и размеры тап-зон.

Также зафиксируйте слова. Скажите модели, что весь текст, подписи, placeholder'ы и подсказки не менять, кроме одной строки, которую редактируете. Это предотвращает молчаливые переписывания, которые меняют смысл.

Короткая подсказка для запроса изменений:

• Оставьте идентичными: маршруты/экраны, порядок навигации и поведение кнопки «назад»
• Оставьте идентичными: сетку вёрстки, отступы, шрифты, цвета и состояния компонентов
• Оставьте идентичными: весь текст и подписи кроме: <the one string>
• Мобильные правила: оставить текущее поведение на <breakpoints>, не рефлоуить другие секции
• Вывод: опишите каждое UI-изменение и перечислите файлы/компоненты, которые затронули

Если возможно, попросите скриншоты до/после. Если скриншотов нет, запросите короткое «UI-diff» описание (что сдвинулось, что изменило размер, что поменяло цвет), чтобы вы могли утвердить с уверенностью.

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

Бизнес-правила — одно из самых лёгких мест, где маленькое UI-правка может создать тихую регрессию. Обновление метки может случайно изменить расчёт, переход статуса или кто видит запись. Обращайтесь с правилами и данными как с контрактами.

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

Пропишите правила, которые нельзя менять

Вместо «сохранить цены такими же», зафиксируйте:

• Ценообразование: точная формула, округление (вверх/вниз), валюта, поведение налогов/НДС и когда применяются скидки
• Права: какие роли могут создавать, редактировать, удалять, утверждать, возвращать деньги, экспортировать или видеть чувствительные поля
• Статусы: допустимые состояния и валидные переходы (и что их триггерит)
• Расчёты: итоги, комиссии, кредитные операции, лимиты и любые потолки или минимумы
• Записи данных: какие таблицы/записи создаются или обновляются и что должно оставаться неизменным

Добавьте один числовой пример, чтобы убрать интерпретации. Например: «Промежуточная сумма заказа $120, скидка 10% (применяется до налога), налог 8.25% от суммы после скидки. Ожидаемый итог = (120 - 12) * 1.0825 = $116.91. Округлять до 2 знаков только в итоговой сумме.»

Укажите видимость по ролям, а не только действия. Пример: «Служба поддержки видит статус заказа и email клиента, но не должна видеть полные данные карты. Только админы могут делать возвраты.»

Если важна валидация — заморозьте её явно. Укажите точный триггер и сообщение пользователю: «Если дата начала после даты окончания — блокировать сохранение и показывать: ‘End date must be after start date.’ Не менять эту формулировку.»

Не забудьте о побочных эффектах за пределами приложения. Если вы отправляете письма, вебхуки или вызываете внешние API — заморозьте то, что должно оставаться таким же: названия событий, поля в payload, тайминг (немедленно или с задержкой) и идемпотентность (нет дублирующих отправок при повторе).

Пошагово: как сделать одно безопасное изменение

Относитесь к небольшому обновлению как к мини-контракту. Шаблон лучше всего работает, когда изменение узкое, а всё остальное явно заморожено.

1. Опишите изменение одним проверяемым предложением. «На странице настроек добавить переключатель для тёмной темы» — проверяемо. «Улучшить UI настроек» — нет. Если вы не можете проверить за 30 секунд, это всё ещё слишком широкая задача.

2. Напишите список заморозки для тех частей, которые повредят при дрейфе: пользовательский поток, ключевые элементы UI, бизнес-правила, поведение данных и любые API или таблицы в БД, которые должны остаться такими же.

3. Добавьте acceptance checks и короткий тест-план. Это предотвращает «работает у меня» сюрпризы. Включите проверки вроде: новый переключатель виден, существующие настройки по-прежнему сохраняются, и ничего больше на странице не сдвинулось.

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

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

Короткий чеклист для ревью:

• Изменилось только запрошенное поведение
• Замороженные потоки и экраны по-прежнему совпадают
• Бизнес-правила и записи данных не поменялись
• Тесты (или ручные шаги) проходят как написано
• Ни одного «clean up» коммита не просочилось

Это особенно удобно в Koder.ai: вставьте список заморозки в Planning Mode, попросите ассистента повторить ограничения, а затем сгенерируйте минимальный патч.

Распространённые ошибки, которые всё ещё вызывают дрейф

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

Одна типичная ловушка — заморозка результата («сделать онбординг проще») вместо точного описания шагов пользователя. Другая — фраза «оставьте всё как есть» и уверенность, что система поймёт, что это значит.

Ошибки, которые чаще всего приводят к дрейфу:

• Абстрактность: вы защищаете намерение, но не пошаговый поток и ожидаемые результаты.
• Пропущенные пограничные случаи: пустые/загрузочные состояния, сообщения об ошибках, поведение при потере соединения.
• Слияние изменений: несколько правок в одном запросе повышают шанс компромиссов и регрессий.
• Неопределённость «идентичности»: та же вёрстка, те же вызовы API, те же записи в БД, те же письма/события аналитики.
• Утверждение по ощущению: «выглядит нормально», но без проверки ключевых путей.

Небольшой пример: вы просите «сделать кнопку более заметной» и замораживаете цвет, но забываете заморозить состояние disabled. Обновление может сделать кнопку всегда доступной, изменив поведение, которое вы заметите только позже.

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

• Пройдите основной поток end-to-end (тот, который вы заморозили).
• Вызовите хотя бы одно ошибочное и одно пустое состояние.
• Проверьте права (admin vs обычный пользователь), если релевантно.
• Подтвердите побочные эффекты: записи созданы/обновлены, уведомления отправлены, логи/метрики не изменились.

Если что-то отличается, значит запрос не включал нужную деталь в список заморозки, а не «плохой код».

Пример: небольшая правка UI без изменения рабочего процесса

Частая безопасная итерация — мелкая полировка UI, где рабочий процесс не может поменяться.

Сценарий: у основателя простой экран регистрации с короткой формой (Name, Email, Company size) и основной кнопкой, которая сабмитит форму и переводит пользователя на Dashboard.

Точное задание (одно предложение): «Переименовать основную кнопку с 'Create account' в 'Continue' и заменить поле 'Company size' с текстового поля на выпадающий список.»

Теперь примените шаблон и заморозьте, что нельзя менять:

• Заморозка потока: сабмит по-прежнему создаёт аккаунт, показывает те же сообщения валидации и переводит пользователя на тот же следующий экран.
• Заморозка UI: вёрстка страницы, отступы, цвета и расположение кнопки остаются прежними.
• Заморозка данных: ключи и типы полезной нагрузки на бэкенд не меняются; сохраняемое значение Company size остаётся в том же формате.
• Заморозка бизнес-правил: обязательность полей остаётся, кнопка остаётся неактивной, пока форма невалидна.
• Заморозка аналитики: те же трекинговые события посылаются при сабмите и при ошибках валидации.

Acceptance checks, которые можно выполнить за минуты:

• Текст кнопки везде отображается как «Continue» (в состоянии по умолчанию, загрузки, disabled).
• Company size — выпадающий список с тем же значением по умолчанию, что было раньше.
• Сабмит всё так же переадресует на Dashboard и аккаунт создаётся.
• Существующие пользователи, редактирующие профиль, видят прежнее сохранённое значение Company size корректно.
• Нет новых предупреждений или падающих тестов в области регистрации.

Хороший ответ ассистента должен повторить замороженные пункты, уточнить любую неясность (например, какие опции должны быть в dropdown и какое значение сохраняется) и затем сделать только минимальное изменение в коде/UI. Он должен также отметить, что специально не трогал (маршрутизацию, логику валидации, форму полезной нагрузки).

Быстрый чеклист перед утверждением обновления

Перед тем как принять «маленькое изменение», сделайте быструю проверку, чтобы найти молчаливый дрейф. Цель не полное QA — цель подтвердить, что приложение по-прежнему ведёт себя в тех частях, где вы сказали «не менять», кроме единственного ожидаемого изменения.

5 быстрых проверок (10 минут)

Выполняйте их в одном и том же порядке. Это сохраняет спокойствие при ревью и облегчает поиск регрессий.

• Критический поток завершается end-to-end: начните с той точки входа, которую используют реальные пользователи (логин, лендинг, dashboard) и выполните основную задачу.
• UI идентичен, кроме намеренного изменения: откройте ключевые экраны из списка заморозки. Проверьте вёрстку, подписи, отступы и навигацию.
• Бизнес-правила совпадают с ожиданием: выборочно проверьте 2–3 случая, которые чаще всего ломаются, например расчёт скидки, права роли или переход статусов.
• Форма данных не изменилась: убедитесь, что нет новых полей, переименованных или удалённых полей, или миграций без контроля.
• Интеграции не тронуты: проверьте, что эндпоинты и полезные нагрузки не поменялись (названия полей, обязательные поля, коды статусов).

Когда откатывать и пересылать запрос

Откатывайте, если хоть один замороженный пункт изменился, даже если приложение «всё ещё работает». Изменённая подпись, новое поле или слегка иная логика — признак того, что модель сделала лишние изменения.

Повторите запрос с более жёсткими ограничениями: кратко повторите одно изменение в одном предложении, перечислите замороженные потоки и экраны по именам и добавьте «без изменений схемы, без изменений эндпоинтов, без изменения поведения за пределами X». Если вы используете Koder.ai, снимок до теста делает откат одним шагом, когда что-то смещается.

Следующие шаги: применяйте это в Koder.ai для безопасных итераций

Если вы работаете в Koder.ai, шаблон «не менять» лучше всего взять за привычку: одно маленькое изменение, всё остальное заблокировано и чёткий путь назад при дрейфе.

Начните с короткого планирования

Перед тем как просить изменение, переключитесь в Planning Mode и попросите ассистента кратко повторить вашу область на простом языке. Попросите его повторить две вещи: (1) точное изменение и (2) ясный список заморозки (потоки, UI детали и бизнес-правила, которые не должны двигаться).

Рабочая подсказка для планирования: «Повторите мой запрос. Затем перечислите, что нельзя менять. Если что-то неясно — задайте вопросы до начала редактирования.»

Защищайте каждую итерацию снимками

Относитесь к каждому запросу на изменение как к контрольной точке. Создайте снимок до правки, затем ещё один после верификации. Если что-то сломалось, откат быстрее, чем попытка исправить плохое изменение.

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

Простой рабочий процесс:

• Создать снимок: «До — поменять только подпись кнопки»
• Провести планирование и подтвердить список заморозки
• Попросить одно изменение и попросить краткую diff-стилистику того, что изменено
• Проверить по чеклисту (UI, потоки, правила, данные)
• Создать снимок: «После — проверено»

Переиспользуйте шаблон по всему стеку

Koder.ai может генерировать веб (React), бэкенд (Go + PostgreSQL) и мобильное (Flutter). Шаблон остаётся тем же, хоть код и меняется. Замораживайте части, которые определяют поведение, а не только файлы.

Если вы правите бэкенд-эндпоинт — заморозьте форму запроса/ответа, правила валидации и записи данных. Если вы правите мобильный экран — заморозьте порядок навигации, значения полей по умолчанию и сообщения об ошибках. Если вы меняете логику в БД — заморозьте смысл существующих строк и делайте безопасные миграции.

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