Запрашивайте отсутствующие ограничения перед программированием с помощью подсказок ассистента

Почему неполные тикеты приводят к неправильному коду

Тикет может выглядеть понятным, но при этом не содержать самого важного правила. «Добавить экспорт в CSV» звучит просто. Но тогда разработчик начинает угадывать: какие поля, какой формат даты, какие роли пользователей, ограничения по размеру файла и что делать с отсутствующими данными. Когда начинается угадывание, код может технически работать и при этом не удовлетворять реальную потребность.

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

Эти предположения часто спрятаны в вещах, о которых тикет ничего не говорит:

• бизнес-правила, живущие в чьей-то голове
• старое поведение, которого пользователи уже ожидают
• ограничения по безопасности или правам доступа
• крайние случаи из-за неопрятных реальных данных

Каждая пропущенная деталь может обернуться переделкой. Команда пишет фичу, ревьюит, тестирует и, может быть, деплоит. И затем кто-то говорит: «Мы же хотели, чтобы этим могли пользоваться только менеджеры» или «Это должно совпадать со старым форматом отчёта». Тогда команде приходится переделывать логику, обновлять тесты, менять UI и объяснять задержку. Вопрос на две минуты в начале сэкономил бы часы.

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

Короткий раунд уточнений обычно дешевле. Одно сообщение вроде «Гости должны видеть эту кнопку и экспорт должен включать архивные записи?» может закрыть самые большие пробелы. Эта небольшая пауза кажется медленной в моменте. На практике она быстрее, чем делать неправильно дважды.

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

Что считается отсутствующим ограничением

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

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

Следующий пробел — это форма самой работы: что приходит на вход и что должно быть на выходе. Тикет «импортировать лидов из CSV» всё ещё оставляет много вопросов. Ассистенту нужен формат файла, обязательные колонки, правила валидации и точный результат, которого ожидает пользователь после загрузки.

Некоторые ограничения кажутся мелочами, но они определяют подход:

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

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

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

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

Как ассистент должен сначала спрашивать

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

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

Спрашивайте только то, что меняет реализацию

Ранжируйте вопросы по влиянию. Хороший ассистент начинает с выборов, которые потребуют переписывания позже.

• Какой провайдер аутентификации использовать?
• Должно ли это работать для существующих пользователей или только для новых?
• Что делать при таймауте внешнего API?
• Нужны ли аудиторские логи или проверки ролей?

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

Частичный тикет может сказать: «Добавить экспорт счетов в админку». Ассистент не должен нырять в код. Он должен спросить, означает ли экспорт CSV, PDF или оба формата, могут ли админы экспортировать все счета или только отфильтрованные результаты, и должен ли файл включать удалённые или возвращённые средства. Три коротких вопроса могут предотвратить часы переделок.

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

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

Простой шаблон подсказки, который спрашивает перед программированием

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

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

You are helping with a software ticket.

Rules:
- Do not guess missing constraints.
- If the ticket is missing details that change the implementation, ask questions first.
- Ask no more than 5 questions.
- Ask only 1 question per missing area.
- After each question, add a short line starting with "Why:" to explain why the answer changes the code.
- Do not write code, pseudocode, file plans, or architecture until the answers arrive.
- After the answers arrive, summarize the confirmed constraints in 3 to 6 bullets, then write the code.

Ticket:
[paste ticket here]

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

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

Это также упрощает ревью для основателя, продакт-менеджера или временного CTO. Им не нужно читать код, чтобы понять, застрял ли ассистент на реальном ограничении или просто шумит. Если ответы отсутствуют, ассистент ждёт. Когда ответы приходят, он программирует с гораздо меньшим числом ошибок.

Реалистичный пример из неполного тикета

В бэклог падает тикет: «Добавить экспорт счетов». Это звучит просто, пока кто-то не начнёт реализовывать. Один разработчик думает, что это CSV для финансовой команды. Другой предполагает, что клиентам нужен PDF для скачивания со страницы биллинга.

Вот где команды теряют время. При неполных тикетах ассистент должен остановиться и спросить отсутствующие ограничения, а не угадывать.

В этом тикете пробелы легко заметить. Какой тип файла хочет продакт-оунер? Кто может им пользоваться? Можно ли экспортировать один счёт, диапазон по датам или всю историю? Что делать, если у аккаунта 30 000 счетов? Относятся ли к файлу черновики, возвращённые или отменённые счета?

Полезная подсказка заставила бы ассистента задать такие вопросы:

• В каком формате должен быть экспорт: CSV, XLSX или PDF?
• Какие роли пользователей могут видеть и запускать экспорт?
• Можно ли экспортировать один счёт, отфильтрованный список или всё сразу?
• Какие ограничения должны действовать для больших экспортов?
• Какие крайние случаи учитывать: черновики, возвраты, часовые пояса, пустые результаты?

Теперь представьте, что продакт-оунер отвечает ясно. Экспорт только в CSV. Админы и владельцы аккаунтов могут им пользоваться, обычные участники — нет. Можно экспортировать по диапазону дат, не более 10 000 строк за раз. Черновики исключаются, возвращённые счёта включаются, даты в файле — в часовом поясе аккаунта.

Это превращает расплывчатый запрос в бриф для разработки: добавить кнопку экспорта CSV на странице биллинга для админов и владельцев аккаунта, поддержать фильтрацию по диапазону дат, заблокировать экспорты свыше 10 000 строк с понятным сообщением и включать возвраты, но не черновики.

Теперь задача тестируема. QA может проверить, что нужные роли видят кнопку, CSV содержит ожидаемые строки, большие экспорты прерываются с правильным сообщением, и метки времени соответствуют настройке аккаунта. Вот разница между быстрым программированием и программированием дважды.

Когда спрашивать, а когда двигаться дальше

Не нужен идеальный тикет, чтобы начать. Если тикет называет пользователя, действие и ожидаемый результат, обычно можно продолжать. «Менеджер экспортирует счета в CSV» — достаточно ясно, чтобы наметить endpoint, триггер UI и базовый тест.

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

Если пробел один и он блокирует безопасный прогресс, задайте один вопрос и ограничьте его. Тикет «Добавить поиск по заказам» может быть почти ясен, но один вопрос всё ещё важен: искать только по ID заказа или по имени клиента тоже? Один короткий вопрос сэкономит переделку.

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

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

Простой способ оценить тикет — спросить, построят ли двое способных читателей одно и то же. Если ответ — нет, остановитесь и спросите. «Добавить уведомления» может означать email, встроенные оповещения, SMS или всё вместе. Два инженера могут действовать добросовестно и при этом выпустить разные фичи.

Этот быстрый фильтр работает так:

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

Последнее правило чаще всего игнорируют, но именно оно предотвращает больше всего потраченного впустую кода.

Частые ошибки в подсказках для уточнений

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

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

Другая распространённая проблема — спрашивать то, что уже указано в тикете. Если тикет говорит, что фича для мобильных пользователей, использует PostgreSQL и должна возвращать CSV, ассистент не должен спрашивать это снова. Это выглядит неаккуратно и подрывает доверие к процессу.

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

Подсказка становится лучше, если вместо расплывчатых слов задаёт конкретные проверки:

• «просто» → «какая минимальная версия приемлема?»
• «быстро» → «какое время отклика или размер батча приемлем?»
• «безопасно» → «какие auth, роли и правила аудита должны быть соблюдены?»

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

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

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

Быстрый чеклист для ревью

Быстрое ревью ловит слабые подсказки до того, как они превратятся в неправильный код. Цель проста: запрашивать отсутствующие ограничения до программирования, пока тикет ещё дешёвый для исправления. Если подсказка оставляет место для угадывания, ассистент обычно угадает.

Прочитайте тикет или подсказку один раз и спросите, сможет ли другой коллега объяснить задачу одним простым предложением. Если нет — задача ещё расплывчата. Короткое суммирование заставляет автора назвать фичу явно, вместо того чтобы прятаться за расплывчатыми формулировками.

Используйте этот быстрый проход перед тем, как отправлять что-либо ассистенту:

• Назовите, кто пользователь, что он делает и что должно произойти после этого действия.
• Укажите правила, которые нельзя менять: права доступа, тайминги, лимиты данных или требуемые форматы.
• Добавьте неловкие случаи: пустой ввод, дубликаты, упавшие API, медленные ответы, частичные сохранения.
• Заставьте ассистента сначала задать вопросы, если отсутствует любое правило, зависимость или крайний случай.
• Опишите, что означает «готово», чтобы ревьюер мог утвердить или отклонить результат без догадок.

Небольшие изменения в формулировке дают большой эффект. «Добавить экспорт» — слабая формулировка. «Админ экспортирует отфильтрованные счета в CSV, с лимитом 10 000 строк и маскировкой email клиентов» — гораздо лучше. Ревьюер может представить поведение, и ассистенту остаётся меньше мест для блуждания.

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

«Готово» должно быть легко протестировать. Ревьюер должен знать, какой ввод попробовать, какой результат ожидать и какие случаи обязаны корректно обрабатываться. Если это всё ещё неясно, тикет не готов.

Одна пропущенная деталь может стоить дня работы. Двухминутный чек чаще всего её ловит.

Что делать дальше с вашей командой

Сделайте одно изменение в процессе первым: каждому новому тикету перед тем, как кто-либо попросит ассистента писать код, нужен чек по уточнениям. Включите этот чек в триаж тикетов, а не в код-ревью. Если в тикете остались вопросы по входам, выходам, лимитам, обработке ошибок или критериям успеха, команда спрашивает эти детали до начала работы.

Это выглядит просто, но убирает много предотвратимой переделки. Команды часто винят модель, тогда как настоящая проблема — в тикете. Запрос «добавить экспорт» звучит ясно, пока один человек не имеет в виду CSV, другой — PDF, и никто не говорит про права доступа, логи аудита или лимиты по размеру файла.

Сохраните одну переиспользуемую подсказку и сделайте её по умолчанию:

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

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

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

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

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

Если вашей команде нужна внешняя помощь, Oleg Sotnikov может проверить ваши подсказки, процесс доставки и шаги утверждения в рамках консультаций Fractional CTO. Такой обзор полезен, когда вы уже используете ИИ для генерации кода, но всё ещё теряете время на расплывчатые тикеты, шумные ответы или несвязанный переход между продуктом и инженерами.

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