From 5e740bdd1ae1ed7e284873b20d40f3730e71efae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC=20=D0=98=D0=B2=D0=B0?= =?UTF-8?q?=D0=BD=D0=BE=D0=B2?= Date: Mon, 3 Aug 2026 19:27:53 +0300 Subject: [PATCH] docs: expand AI development, prompting, and testing answers --- src/pages/ai/index.md | 682 ++++++++++++++++++++++++++++-------------- 1 file changed, 463 insertions(+), 219 deletions(-) diff --git a/src/pages/ai/index.md b/src/pages/ai/index.md index 4c26362..d620c21 100644 --- a/src/pages/ai/index.md +++ b/src/pages/ai/index.md @@ -21,16 +21,28 @@ icon: /logos/claude-icon.svg **Короткий ответ** -AI-assisted development - это разработка, где инженер использует модель как помощника: просит объяснить код, -сгенерировать черновик функции, написать тест, найти ошибку, предложить рефакторинг или подготовить документацию. +AI-assisted development - это разработка, где инженер использует модель как помощника: для анализа кода, генерации +черновиков, тестов, документации и поиска ошибок. Ответственность за решение и итоговый diff остается у инженера. **Полный ответ** -AI-assisted development - это разработка, где инженер использует модель как помощника: просит объяснить код, -сгенерировать черновик функции, написать тест, найти ошибку, предложить рефакторинг или подготовить документацию. +AI-assisted development - это рабочий процесс, в котором модель ускоряет отдельные этапы разработки, но не становится +самостоятельным владельцем результата. Она может объяснить незнакомый модуль, предложить варианты реализации, написать +черновик теста, найти подозрительное место в diff или подготовить документацию. -Важный момент: ответственность остается у инженера. AI может ускорить работу, но результат нужно понимать, проверять и -доводить до стандартов проекта. +Обычно процесс выглядит так: + +1. Инженер формулирует задачу, ограничения и критерии приемки. +2. Модель изучает предоставленный контекст и предлагает план или изменение. +3. Инженер проверяет предположения, diff, типы, тесты и влияние на архитектуру. +4. Результат дорабатывается и проходит обычный review и CI. + +Главное преимущество - снижение стоимости исследования и рутины. Например, модель может быстро найти все места, где +используется устаревший API, и подготовить механический черновик миграции. Риск в том, что правдоподобный ответ легко +принять за корректный: модель не знает все неявные бизнес-правила, production-инциденты и договоренности команды. + +На интервью полезно подчеркнуть, что AI меняет скорость получения черновика, но не критерии качества. Автор изменения +должен понимать код, уметь объяснить trade-offs и отвечать за последствия после merge. @@ -42,16 +54,28 @@ AI-assisted development - это разработка, где инженер и **Короткий ответ** -Поиск возвращает источники, а AI сразу синтезирует ответ под контекст задачи. Это удобно, когда нужно быстро получить -черновик решения, сравнить варианты или разобраться в незнакомом коде. +Поиск помогает найти источники, а AI синтезирует ответ под контекст задачи и может сразу предложить код. Поиск удобнее +для проверки фактов, а AI - для анализа, сравнения вариантов и подготовки черновика. **Полный ответ** -Поиск возвращает источники, а AI сразу синтезирует ответ под контекст задачи. Это удобно, когда нужно быстро получить -черновик решения, сравнить варианты или разобраться в незнакомом коде. +Поисковая система в основном ранжирует документы и оставляет пользователю задачу прочитать источники, сопоставить версии +и собрать решение. AI-помощник получает описание задачи, фрагменты проекта и ограничения, после чего формирует связный +ответ: объяснение, план, код или тесты. + +Различие влияет на способ проверки: -Но у AI есть риск уверенно ошибаться. Поэтому ответы нужно проверять по документации, тестам, коду проекта и -ограничениям конкретной системы. +- у поиска видны первичные источники, даты и авторы; +- AI может объединить несколько идей, но не всегда показывает, откуда взял утверждение; +- поиск хуже учитывает локальный контекст проекта; +- AI может придумать несуществующий API или уверенно использовать устаревший паттерн. + +Например, для вопроса «какой метод появился в новой версии framework» надежнее открыть официальную документацию. Для +задачи «сравни два варианта рефакторинга с учетом этого компонента и тестов» AI может быстрее подготовить анализ. + +Практичный процесс сочетает оба инструмента: AI помогает сформулировать гипотезу и найти область исследования, а +официальная документация, исходный код, тесты и воспроизводимый эксперимент подтверждают вывод. На интервью важно не +противопоставлять AI и поиск, а показать, что у них разные роли и уровень доверия. @@ -63,20 +87,31 @@ AI-assisted development - это разработка, где инженер и **Короткий ответ** -Лучше начинать с задач с понятными границами и быстрым способом проверки: +Безопаснее начинать с ограниченных задач, где ошибку легко заметить: объяснение кода, boilerplate по существующему +примеру, черновик теста, варианты названий, список edge cases и описание PR. **Полный ответ** -Лучше начинать с задач с понятными границами и быстрым способом проверки: +Лучшие первые задачи имеют три свойства: небольшой scope, понятный ожидаемый результат и дешевую проверку. Модель можно +использовать, чтобы: + +- объяснить существующий код и построить карту зависимостей; +- написать boilerplate по уже принятому в проекте примеру; +- предложить тест-кейсы или черновик unit-теста; +- найти повторяющийся код и варианты именования; +- подготовить summary diff или документацию; +- перечислить потенциальные edge cases перед реализацией. -- объяснить существующий код; -- написать черновик unit-теста; -- предложить варианты названий; -- сгенерировать boilerplate по существующему примеру; -- найти очевидные edge cases; -- подготовить краткое описание Pull Request. +Например, генерацию mapper-функции с известными входными и выходными типами легко проверить компилятором и тестами. +Изменение схемы авторизации, миграцию данных или удаление production-ресурсов нельзя отдавать модели с тем же уровнем +самостоятельности: цена скрытой ошибки намного выше. -Чем хуже сформулированы требования и чем выше цена ошибки, тем больше контроля должен оставаться у человека. +Полезно оценивать риск по четырем вопросам: насколько четко сформулировано требование, можно ли автоматически проверить +результат, насколько обратимо изменение и какой будет ущерб при ошибке. Чем хуже ответы, тем меньше autonomy и тем +больше approval points должно быть в процессе. + +На интервью сильный ответ содержит не только список задач, но и критерий выбора: начинать с того, что ограничено, +обратимо и проверяемо. @@ -88,18 +123,30 @@ AI-assisted development - это разработка, где инженер и **Короткий ответ** -Vibe coding - это подход, при котором разработчик в основном формулирует намерение, а AI генерирует значительную часть -кода. Человек меньше пишет синтаксис вручную и больше управляет задачей: уточняет требования, проверяет результат, -запускает тесты, ревьюит diff и направляет модель следующими запросами. +Vibe coding - это подход, при котором разработчик описывает желаемый результат, а AI генерирует значительную часть кода. +Он ускоряет прототипирование, но без строгой проверки может привести к непонятному коду и техническому долгу. **Полный ответ** -Vibe coding - это подход, при котором разработчик в основном формулирует намерение, а AI генерирует значительную часть -кода. Человек меньше пишет синтаксис вручную и больше управляет задачей: уточняет требования, проверяет результат, -запускает тесты, ревьюит diff и направляет модель следующими запросами. +При vibe coding человек управляет разработкой через намерения и обратную связь: описывает, что должно работать, +запускает результат, сообщает модели об ошибках и просит следующую итерацию. Ручного написания синтаксиса становится +меньше, а доля сгенерированного кода - больше. + +Подход хорошо работает для прототипов, внутренних утилит и небольших задач с ясными границами. Он позволяет быстро +проверить идею или собрать первый вариант интерфейса. Проблемы начинаются, когда прототип незаметно становится +production-кодом, а команда не понимает архитектуру, инварианты и причины решений. + +Типичные риски: -Подход может резко ускорить простые и хорошо ограниченные задачи, но не отменяет инженерную ответственность. Если -команда мерджит AI-код без понимания, она быстро накапливает хрупкость и технический долг. +- модель исправляет симптомы вместо причины; +- каждая следующая правка добавляет еще один workaround; +- diff становится слишком большим для содержательного review; +- тесты подтверждают текущую реализацию, а не требуемое поведение; +- автор не может безопасно изменить код без новой генерации. + +Зрелый вариант vibe coding сохраняет короткий feedback loop, но добавляет план, ограничения, маленькие commits, тесты и +ревью diff. На интервью стоит разделить быстрый эксперимент и поддерживаемую разработку: для них допустим разный уровень +формальности. См. обсуждение: [Hacker News: vibe coding](https://news.ycombinator.com/item?id=48823359). @@ -113,21 +160,29 @@ Vibe coding - это подход, при котором разработчик **Короткий ответ** -Фокус смещается с набора кода к постановке задачи, декомпозиции, архитектуре, проверке инвариантов и коммуникации с -заказчиками. Инженер все еще отвечает за то, что система делает правильно, безопасно и поддерживаемо. +Фокус смещается с ручного набора кода к постановке задачи, декомпозиции, архитектуре, проверке инвариантов и review. +Инженер по-прежнему отвечает за корректность, безопасность и поддерживаемость системы. **Полный ответ** -Фокус смещается с набора кода к постановке задачи, декомпозиции, архитектуре, проверке инвариантов и коммуникации с -заказчиками. Инженер все еще отвечает за то, что система делает правильно, безопасно и поддерживаемо. +Генерация делает синтаксис дешевле, поэтому большую ценность получают действия, которые определяют направление решения: +понимание пользовательской проблемы, выбор границ модулей, формулировка контрактов, оценка рисков и проверка результата. + +В AI-процессе инженер должен уметь: + +- дать модели только релевантный контекст и четкие ограничения; +- разбить задачу на маленькие проверяемые шаги; +- отличить локально работающий код от архитектурно подходящего; +- читать diff, находить скрытые изменения поведения и security-риски; +- проектировать тесты, которые проверяют требования, а не текст генерации; +- объяснить решение команде и поддерживать его после merge. -Хороший инженер в AI-процессе умеет: +Например, AI может написать форму и API-adapter, но инженер решает, где хранится состояние, как обрабатывается повторная +отправка, что происходит при частичном ответе сервера и какие данные разрешено логировать. -- задавать модели маленькие проверяемые задачи; -- читать diff и находить скрытые регрессии; -- понимать архитектурные последствия изменений; -- писать или требовать тесты; -- отличать рабочий прототип от кода, который можно поддерживать годами. +Риск состоит в деградации навыков, если человек становится только оператором prompt. Поэтому полезно периодически решать +задачи без генерации, самостоятельно строить план и разбирать ошибки модели. На интервью важно показать, что роль +инженера не исчезает: она поднимается на уровень решений и контроля качества. @@ -139,23 +194,29 @@ Vibe coding - это подход, при котором разработчик **Короткий ответ** -AI оптимизирует ответ под запрос, а не под долгосрочные интересы проекта. Он может сгенерировать код, который проходит -happy path, но нарушает архитектурные границы, ухудшает доступность, дублирует бизнес-правила, игнорирует ошибки или -создает неочевидные состояния. +AI оптимизирует ответ под prompt, а не под долгосрочные интересы проекта. Код может проходить happy path, но нарушать +архитектурные границы, безопасность, accessibility или неявные бизнес-правила. **Полный ответ** -AI оптимизирует ответ под запрос, а не под долгосрочные интересы проекта. Он может сгенерировать код, который проходит -happy path, но нарушает архитектурные границы, ухудшает доступность, дублирует бизнес-правила, игнорирует ошибки или -создает неочевидные состояния. +Модель генерирует наиболее вероятное продолжение на основании доступного контекста. Она не присутствовала на прошлых +архитектурных обсуждениях, не несет on-call и может не увидеть код, который не попал в context window. Поэтому внешне +аккуратный diff не гарантирует корректного решения. -Ревью должно проверять не только стиль, но и смысл: +При review нужно проверить несколько уровней: -- правильно ли понято требование; -- нет ли лишней абстракции; -- сохранены ли публичные контракты; -- покрыты ли важные сценарии тестами; -- можно ли следующему инженеру безопасно изменить этот код. +- **требование:** решена ли исходная пользовательская проблема; +- **поведение:** обработаны ли ошибки, пустые данные, повторные действия и concurrency; +- **архитектура:** не нарушены ли границы модулей и публичные контракты; +- **безопасность:** нет ли утечки данных, расширения permissions или injection-risk; +- **поддержка:** понятны ли имена, причины абстракций и будущая точка изменения; +- **проверки:** тесты действительно ловят регрессию, а CI проходит. + +Особенно опасно доверять факту, что модель сама написала и реализацию, и тест: они могут разделять одно ошибочное +предположение. Независимое чтение требования и негативные сценарии снижают этот риск. + +AI-код проходит тот же review, что и ручной, а для большого или незнакомого diff контроль должен быть строже. На +интервью полезно сказать: происхождение кода не меняет ответственность автора. @@ -167,18 +228,30 @@ happy path, но нарушает архитектурные границы, у **Короткий ответ** -AI slop - это внешне правдоподобный код низкого качества: много лишних слоев, случайные названия, неполные edge cases, -дублирование, неиспользуемые ветки, слабая типизация и решения, которые выглядят уверенно, но плохо вписываются в -проект. +AI slop - это правдоподобный, но низкокачественный сгенерированный код: лишние абстракции, дублирование, случайные +имена, слабая типизация, мертвые ветки и неполная обработка сценариев. **Полный ответ** -AI slop - это внешне правдоподобный код низкого качества: много лишних слоев, случайные названия, неполные edge cases, -дублирование, неиспользуемые ветки, слабая типизация и решения, которые выглядят уверенно, но плохо вписываются в -проект. +AI slop возникает, когда скорость генерации не сопровождается инженерным отбором. Каждый отдельный фрагмент может +выглядеть разумно, но вместе они создают систему без ясных границ и единого стиля. + +Характерные признаки: + +- новая универсальная abstraction решает только один локальный случай; +- одинаковое бизнес-правило реализовано в нескольких местах; +- добавлены зависимости или helpers, которые почти не используются; +- типы заменены на `any`, необоснованные assertions или широкие unions; +- комментарии пересказывают код, но не объясняют причины; +- обработан happy path, а ошибки и cleanup забыты; +- тесты проверяют детали реализации и создают ложное чувство покрытия. -Проблема slop не в том, что код сгенерирован AI, а в том, что его приняли без инженерного отбора. Хороший процесс -оставляет скорость генерации, но добавляет жесткую проверку требований, типов, тестов и архитектурных границ. +Причина не в самом использовании AI. Такой же код может написать человек под давлением срока. Разница в том, что модель +способна производить большой объем правдоподобного текста очень быстро, поэтому review становится узким местом. + +Снижать slop помогают маленькие задачи, ограничение файлов, существующие примеры проекта, обязательное удаление лишнего +и вопрос к каждой новой abstraction: какое реальное изменение она упрощает. На интервью хорошо привести конкретный +пример, а не ограничиваться формулировкой «AI пишет плохой код». @@ -190,20 +263,27 @@ AI slop - это внешне правдоподобный код низкого **Короткий ответ** -Нужны ограничения, которые делают AI ускорителем, а не источником неконтролируемых изменений: +Нужны маленькие задачи, минимальные права, явные approvals, review diff и обычные проверки проекта: lint, typecheck, +tests, security scanning и build. После merge команда должна понимать код не хуже, чем при ручной разработке. **Полный ответ** -Нужны ограничения, которые делают AI ускорителем, а не источником неконтролируемых изменений: +Безопасный процесс строится слоями, потому что ни prompt, ни sandbox, ни CI по отдельности не дают полной защиты. + +1. **До генерации:** определить требование, scope, запрещенные изменения и критерии приемки. +2. **Контекст:** предоставить только нужные файлы, не передавать секреты и персональные данные. +3. **Права:** начинать с read-only, отдельно подтверждать shell, сеть, установку зависимостей и destructive actions. +4. **Изменение:** делать небольшой diff и не смешивать feature, refactoring и форматирование. +5. **Проверка:** читать diff, запускать typecheck, tests, lint, build и security-проверки. +6. **Review:** автор объясняет решение, trade-offs и остаточные риски своими словами. +7. **Наблюдаемость:** для командных агентов полезно хранить audit trail действий и версию используемой модели. -- задачи дробятся на небольшие PR; -- каждый PR имеет понятное требование и критерии приемки; -- AI-код проходит обычные проверки: lint, typecheck, tests, review; -- ревьюер смотрит diff, а не только итоговую демонстрацию; -- архитектурные изменения обсуждаются человеком до генерации; -- команда фиксирует промпты, trade-offs и известные ограничения, если они важны для поддержки. +Например, агент может самостоятельно найти место ошибки и подготовить patch, но изменение схемы базы, публикация пакета +или отправка данных во внешний сервис должны требовать отдельного подтверждения. -Самый здоровый критерий: после мержа команда должна понимать код не хуже, чем если бы написала его вручную. +Важно учитывать prompt injection: README, issue или web page являются недоверенными данными и не должны автоматически +расширять полномочия агента. На интервью сильный ответ связывает скорость с blast radius: чем опаснее действие, тем +меньше автономность и больше независимых проверок. @@ -215,19 +295,33 @@ AI slop - это внешне правдоподобный код низкого **Короткий ответ** -AI ускоряет разработку, когда команда лучше формулирует задачи, быстрее проверяет гипотезы и сохраняет качество -архитектуры. Это похоже на мощный инструмент автоматизации: он снимает рутину, но не принимает продуктовые и инженерные -решения за команду. +AI ускоряет работу, пока команда лучше формулирует задачи, быстрее проверяет гипотезы и сохраняет понимание системы. +Деградация начинается, когда код мерджат без объяснения решений и проверяемых гарантий. **Полный ответ** -AI ускоряет разработку, когда команда лучше формулирует задачи, быстрее проверяет гипотезы и сохраняет качество -архитектуры. Это похоже на мощный инструмент автоматизации: он снимает рутину, но не принимает продуктовые и инженерные -решения за команду. +Скорость полезна, когда уменьшается время до качественного результата: быстрее найден root cause, написан тест, +проверена гипотеза или подготовлен небольшой diff. Количество сгенерированных строк само по себе ничего не говорит о +прогрессе. + +Признаки здорового использования: -Деградация начинается, когда код перестают понимать. Если изменения мерджатся потому, что "работает на демо", но никто -не может объяснить инварианты, границы ответственности и последствия следующего изменения, скорость становится формой -долга. +- PR становятся меньше или не растут; +- lead time сокращается без увеличения defect rate и rollback; +- разработчики лучше формулируют acceptance criteria; +- AI помогает находить риски и тесты, а не только писать implementation; +- команда может поддерживать изменения без постоянного обращения к той же модели. + +Признаки деградации: + +- никто не может объяснить инварианты кода; +- review превращается в поверхностное подтверждение большого diff; +- растет число случайных abstractions и регрессий; +- инженеры перестают читать документацию и самостоятельно отлаживать; +- краткосрочная скорость оплачивается более медленными следующими изменениями. + +Граница проходит не по проценту AI-generated кода, а по сохранению ownership и обратной связи. На интервью полезно +предложить измеримые сигналы: defect rate, время review, частоту rollback и способность команды изменять код дальше. @@ -239,22 +333,30 @@ AI ускоряет разработку, когда команда лучше **Короткий ответ** -Ревью AI-кода должно быть даже строже обычного, потому что модель может создать убедительный, но чуждый проекту стиль. -Полезный порядок проверки: +Сначала проверить требование и размер diff, затем архитектуру, типы, ошибки, безопасность и тесты. Автор должен +объяснить ключевые решения своими словами; иначе PR не готов. **Полный ответ** -Ревью AI-кода должно быть даже строже обычного, потому что модель может создать убедительный, но чуждый проекту стиль. -Полезный порядок проверки: +Review лучше начинать не с первой строки кода, а с вопроса, какое поведение должно измениться. Это защищает от ситуации, +когда большой аккуратный diff решает соседнюю задачу. -1. Сначала понять требование и ожидаемое поведение. -2. Посмотреть, не слишком ли широким получился diff. -3. Проверить архитектурные границы и зависимости. -4. Проверить типы, обработку ошибок, пустые состояния и edge cases. -5. Убедиться, что тесты ловят важное поведение, а не повторяют реализацию. -6. Попросить автора объяснить ключевые решения своими словами. +Практичный порядок: -Если автор не может объяснить код, PR еще не готов, даже если его сгенерировала сильная модель. +1. Сопоставить PR с issue и acceptance criteria. +2. Проверить, нет ли случайных файлов, refactoring и зависимостей вне scope. +3. Просмотреть публичные контракты, data flow и архитектурные границы. +4. Проверить ошибки, loading, empty states, cleanup, concurrency и backward compatibility. +5. Отдельно посмотреть auth, permissions, пользовательские данные и места возможной injection. +6. Убедиться, что тесты проверяют поведение и падают при реальной регрессии. +7. Запустить релевантные проверки и изучить не только итоговый экран, но и diff. + +Полезно попросить автора отметить, где AI использовался, какие предположения проверены и какие риски остались. Это не +снимает ответственность, а помогает направить внимание reviewer. + +Если автор не может объяснить, почему код расположен именно здесь, зачем нужна новая abstraction и как система поведет +себя при ошибке, PR следует уменьшить или переработать. На интервью это показывает зрелый процесс, а не недоверие к +конкретному инструменту. @@ -268,26 +370,30 @@ AI ускоряет разработку, когда команда лучше **Короткий ответ** -Хорошая задача для AI-агента содержит контекст, цель, ограничения и способ проверки. Вместо "почини форму" лучше -написать: где форма находится, что сейчас происходит, какое поведение ожидается, какие файлы вероятно затронуты, какие -тесты запустить и чего менять нельзя. +Хорошая задача для AI-агента содержит контекст, конкретную цель, ограничения, критерии приемки и команды проверки. Чем +яснее границы и ожидаемый результат, тем меньше случайных изменений и неверных предположений. **Полный ответ** -Хорошая задача для AI-агента содержит контекст, цель, ограничения и способ проверки. Вместо "почини форму" лучше -написать: где форма находится, что сейчас происходит, какое поведение ожидается, какие файлы вероятно затронуты, какие -тесты запустить и чего менять нельзя. +AI-агенту недостаточно общего пожелания вроде «почини форму». Модель должна понять, где находится проблема, какое +поведение наблюдается сейчас, что считается правильным результатом и какие части системы нельзя менять. Полезная +постановка задачи состоит из нескольких блоков: -Практичная структура: +- **контекст:** пользовательский сценарий, релевантный модуль и существующие договоренности проекта; +- **цель:** одно проверяемое изменение поведения; +- **ограничения:** допустимые файлы, публичные контракты, зависимости и архитектурные границы; +- **критерии приемки:** конкретные случаи, которые должны работать после изменения; +- **проверка:** тесты, lint, typecheck, build или ручной сценарий; +- **формат результата:** например, сначала план, затем минимальный diff и список остаточных рисков. -- контекст проекта и пользовательский сценарий; -- ожидаемый результат; -- ограничения по архитектуре, стилю и зависимостям; -- критерии приемки; -- команды проверки; -- просьба сначала объяснить план, если задача рискованная. +Например, вместо «исправь сохранение профиля» лучше указать: при двойном нажатии отправляются два запроса; нужно +блокировать повторную отправку до завершения первого запроса, не менять API сервиса и добавить тест на повторный клик. +Так агент может проверить гипотезу и не переписывать соседнюю форму целиком. -Чем точнее рамки, тем меньше шанс получить большой случайный diff. +Слишком длинный prompt тоже не гарантирует качество. Если в нем смешаны несколько целей и противоречивые инструкции, +модель начинает угадывать приоритеты. Для сложной задачи полезно сначала попросить агента пересказать требование, +перечислить неизвестные и предложить план. На интервью стоит показать, что хороший prompt похож не на магическую фразу, +а на качественную инженерную постановку задачи. @@ -299,21 +405,27 @@ AI ускоряет разработку, когда команда лучше **Короткий ответ** -Техническое задание описывает, что нужно бизнесу или пользователю. Prompt дополнительно управляет работой модели: какой -контекст учитывать, как декомпозировать задачу, какие ограничения соблюдать, как возвращать результат и какие проверки -выполнить. +Техническое задание описывает требуемый продуктовый результат. Prompt дополнительно управляет работой модели: какой +контекст изучить, как действовать, какие ограничения соблюдать и как проверить результат. **Полный ответ** -Техническое задание описывает, что нужно бизнесу или пользователю. Prompt дополнительно управляет работой модели: какой -контекст учитывать, как декомпозировать задачу, какие ограничения соблюдать, как возвращать результат и какие проверки -выполнить. +Техническое задание отвечает прежде всего на вопрос **что и зачем должно измениться** для пользователя или бизнеса. Оно +может существовать независимо от того, кто реализует задачу: человек, команда или AI-агент. Prompt является рабочей +инструкцией для конкретного запуска модели и отвечает на вопросы **как исследовать задачу, чем ограничиться и в каком +виде вернуть результат**. + +Например, техническое задание может требовать сохранять черновик формы после перезагрузки страницы. Prompt для агента +добавит локальный контекст: где находится форма, какой storage abstraction принят в проекте, какие поля нельзя +сохранять, какой тестовый стиль использовать и какие команды запустить. -Для простых задач prompt может быть коротким. Для сложных задач он похож на рабочую инструкцию: "сначала исследуй", "не -меняй публичный API", "добавь тест на регрессию", "после изменений запусти typecheck". +Важно не пытаться заменить слабое требование подробным prompt. Если неизвестно, какие данные считаются черновиком, когда +они протухают и как ведут себя несколько вкладок, модель лишь замаскирует продуктовую неопределенность техническим +текстом. Сначала команда уточняет требование и acceptance criteria, затем превращает их в инструкцию для агента. -Если prompt подменяет собой нормальное требование, команда рискует быстро получить код, который технически сделан, но -решает не ту продуктовую задачу. +На интервью полезно сформулировать различие так: техническое задание определяет контракт результата, а prompt управляет +процессом получения одного из вариантов реализации. Prompt можно менять и экспериментировать с ним, но он не должен +незаметно менять продуктовую цель. @@ -325,22 +437,32 @@ AI ускоряет разработку, когда команда лучше **Короткий ответ** -Типовые признаки: +Тревожные признаки: агент меняет слишком много файлов, решает соседнюю проблему, игнорирует conventions, придумывает +API, удаляет важные проверки или не может связать предложенный diff с критериями приемки. **Полный ответ** -Типовые признаки: +Непонимание часто видно еще до запуска тестов. Агент может уверенно писать код, но его действия расходятся с исходной +целью. Типовые сигналы: -- модель меняет больше файлов, чем нужно; -- решает соседнюю проблему вместо заявленной; -- игнорирует локальные conventions; -- удаляет edge cases или тесты; -- придумывает несуществующие API; -- добавляет универсальную абстракцию для локальной задачи; -- не может объяснить, почему выбран именно такой подход. +- план пересказывает названия файлов, но не объясняет требуемое поведение; +- diff значительно шире области ошибки; +- вместе с исправлением выполняется несогласованный refactoring; +- используются несуществующие методы, устаревшие API или чуждый проекту паттерн; +- удаляются edge cases, guards или тесты, которые мешают предложенному решению; +- новая abstraction не связана с реальной точкой изменения; +- агент объявляет задачу завершенной, не проверив acceptance criteria. -В такой ситуации лучше остановить генерацию, сузить задачу и попросить сначала сформулировать план или воспроизвести -проблему. +Например, проблема может быть в неверном условии disabled-состояния, а модель предложит заменить всю форму, state +management и API-client. Даже если код компилируется, масштаб изменения показывает, что агент оптимизировал локальное +предположение, а не понял ограничение задачи. + +В такой ситуации не стоит продолжать цепочку исправлений поверх неверной основы. Лучше остановиться, попросить агента +своими словами описать текущее и ожидаемое поведение, указать минимальную область изменения и перечислить неизвестные. +Иногда полезно дать failing test или конкретный пример входа и выхода. + +На интервью сильный кандидат говорит не только «я уточню prompt», но и называет наблюдаемые признаки непонимания и +точку, в которой прекращает генерацию до появления общего понимания задачи. @@ -352,21 +474,32 @@ AI ускоряет разработку, когда команда лучше **Короткий ответ** -Задачу стоит дробить по проверяемым шагам: +Нужно делить работу на проверяемые этапы: воспроизвести проблему, найти минимальную область, зафиксировать поведение +тестом, внести одно изменение и запустить релевантные проверки. Refactoring и изменение поведения лучше разделять. **Полный ответ** -Задачу стоит дробить по проверяемым шагам: +Хорошая декомпозиция уменьшает одновременно риск модели и стоимость review. Каждый шаг должен иметь наблюдаемый +результат, после которого человек может решить, продолжать ли работу. Практичная последовательность: + +1. Описать или воспроизвести текущее поведение. +2. Найти минимальный набор связанных файлов и контрактов. +3. Сформулировать инварианты и acceptance criteria. +4. Добавить failing test или другой способ воспроизведения. +5. Сделать минимальное изменение, которое исправляет один сценарий. +6. Запустить локальные проверки и прочитать diff. +7. Отдельно решить, нужен ли последующий refactoring. + +Например, миграцию на новый API не стоит формулировать как «обнови весь проект». Сначала можно обновить один типичный +consumer, согласовать паттерн, затем механически перенести остальные случаи и отдельным шагом удалить compatibility +layer. Так легче заметить исключения и откатить неудачное решение. -1. Воспроизвести или описать проблему. -2. Найти минимальную область кода. -3. Добавить или обновить тест. -4. Сделать маленькое изменение. -5. Запустить релевантные проверки. -6. Только потом расширять область, если это действительно нужно. +Полезно ограничивать не только количество файлов, но и виды изменений. Если агент одновременно меняет поведение, +переименовывает сущности, форматирует соседний код и обновляет зависимости, reviewer не может надежно определить причину +регрессии. Маленькие commits и PR сохраняют причинно-следственную связь. -AI лучше работает, когда каждый шаг имеет понятный результат. Большой prompt "сделай всю фичу" часто приводит к смешению -требований, рефакторинга, форматирования и случайных улучшений. +На интервью стоит объяснить, что декомпозиция нужна не потому, что AI «слабый», а потому, что проверяемые изменения +ускоряют обратную связь, уменьшают blast radius и делают ответственность понятной для всей команды. @@ -378,19 +511,30 @@ AI лучше работает, когда каждый шаг имеет пон **Короткий ответ** -Маленькая итерация проще для модели и для ревьюера. В ней легче понять намерение, проверить diff, найти ошибку и -откатить изменение. +Маленькую итерацию проще понять, проверить и откатить. Она снижает число предположений в одном запуске и позволяет +скорректировать направление до того, как ошибка распространится на UI, API, state и тесты. **Полный ответ** -Маленькая итерация проще для модели и для ревьюера. В ней легче понять намерение, проверить diff, найти ошибку и -откатить изменение. +При большой генерации модель должна одновременно принять много связанных решений: структуру компонентов, контракты API, +управление состоянием, обработку ошибок, тестовую стратегию и тексты интерфейса. Ошибка в раннем предположении затем +повторяется во всех слоях, а итоговый diff выглядит внутренне согласованным, хотя решает не ту задачу. -Большая генерация часто выглядит впечатляюще, но в ней смешиваются решения разных уровней: UI, API, state, тесты, -архитектура и copy. Если там спрятана ошибка, ее дороже найти. +Маленькие итерации создают короткий feedback loop: -Хороший рабочий режим: модель предлагает план, человек подтверждает границы, затем агент делает один проверяемый шаг и -показывает diff. +1. Агент предлагает план или исследование. +2. Человек подтверждает границы и спорные решения. +3. Агент реализует один вертикальный или технический шаг. +4. Команда проверяет поведение и diff. +5. Следующая итерация строится уже на подтвержденном результате. + +Например, для сложной формы сначала можно согласовать data model и validation rules, затем реализовать один основной +сценарий, после этого добавить ошибки сети и только потом оптимистичное обновление. Просьба «сделай всю форму» скрывает +точки, где требуется продуктовое или архитектурное решение. + +Недостаток маленьких итераций — дополнительные переключения и необходимость поддерживать план. Для простого, +детерминированного изменения один проход может быть дешевле. Поэтому размер шага выбирают по риску и неопределенности, а +не по жесткому правилу «один файл за раз». @@ -402,22 +546,29 @@ AI лучше работает, когда каждый шаг имеет пон **Короткий ответ** -Минимальная проверка: +Нужно прочитать diff целиком, связать изменения с требованием, проверить типы, ошибки и безопасность, удалить случайный +код, запустить релевантные тесты, lint и build, а затем суметь объяснить решение своими словами. **Полный ответ** -Минимальная проверка: +Проверка начинается не с запуска CI, а с сопоставления diff с задачей. Автоматические проверки подтверждают часть +свойств кода, но не доказывают, что модель правильно поняла пользовательский сценарий. Перед commit полезно пройти +несколько уровней: + +- **scope:** изменены только необходимые файлы и нет случайного refactoring; +- **поведение:** happy path, ошибки, loading, empty states, повторные действия и cleanup; +- **контракты:** типы, публичный API, backward compatibility и формат данных; +- **безопасность:** секреты, permissions, injection, логирование и внешние зависимости; +- **поддержка:** понятные имена, отсутствие мертвого кода и оправданность abstractions; +- **проверки:** тесты, lint, typecheck, build и при необходимости ручной сценарий. -- прочитать diff целиком; -- убедиться, что задача решена именно в нужном месте; -- убрать случайные refactoring и лишние зависимости; -- проверить типы, ошибки, loading и empty states; -- запустить релевантные тесты, lint и build; -- посмотреть, нет ли секретов, debug-кода и временных комментариев; -- объяснить решение своими словами. +Особое внимание нужно уделять коду и тестам, сгенерированным одним prompt. Они могут разделять одно ошибочное +предположение, поэтому зеленый тест не является независимым доказательством. Полезно временно сломать важное поведение и +убедиться, что тест действительно падает. -Если автор не может объяснить изменение, его рано коммитить. AI может быть соавтором черновика, но ответственность за -commit остается у инженера. +Перед commit автор должен уметь объяснить, почему изменение находится именно в этом месте, какие альтернативы +рассматривались и какой риск остается. Если объяснение сводится к «модель так предложила», работа еще не стала +инженерным решением. @@ -429,20 +580,32 @@ commit остается у инженера. **Короткий ответ** -Нужно вернуть задачу к минимальному изменению. Полезные действия: +Нужно остановить широкий rewrite и вернуть задачу к минимальному изменению: ограничить файлы и API, разделить поведение +и refactoring, попросить обязательные и optional шаги и сравнить вариант с меньшим diff. **Полный ответ** -Нужно вернуть задачу к минимальному изменению. Полезные действия: +Большой diff не обязательно плох, но его масштаб должен следовать из осознанного архитектурного решения, а не из +удобства генерации. Если агент начинает переписывать соседние модули, сначала нужно выяснить причину: существующий +контракт действительно блокирует задачу или модель просто предпочла знакомый ей паттерн. -- попросить модель перечислить, какие изменения обязательны, а какие optional; -- запретить менять публичный API без отдельного согласования; -- ограничить список файлов; -- потребовать сначала failing test; -- разделить refactoring и поведенческое изменение на разные PR; -- попросить альтернативу с меньшим diff. +Полезные действия: -Большой rewrite может быть оправдан, но это архитектурное решение, а не побочный эффект генерации. +- попросить перечислить минимально необходимые изменения отдельно от улучшений; +- запретить менять публичный API и зависимости без согласования; +- задать allowlist файлов или модулей; +- потребовать сначала failing test для исходной проблемы; +- попросить альтернативу, сохраняющую текущую архитектуру; +- вынести cleanup и refactoring в отдельную задачу; +- сравнить стоимость поддержки минимального fix и полноценной миграции. + +Например, для поддержки нового поля модель может предложить заменить общий form engine. Возможно, это действительно +нужно, но такое решение требует анализа всех consumers, плана миграции и отдельного review. Для текущей задачи может +быть безопаснее локально расширить существующий контракт. + +Если минимальный вариант создает опасный workaround, не нужно искусственно уменьшать diff. Тогда агент должен показать +причину широкого изменения, список затронутых контрактов, план по этапам и способ отката. На интервью важно показать +баланс: маленький diff — средство контроля, а не самоцель. @@ -454,18 +617,32 @@ commit остается у инженера. **Короткий ответ** -Безопасный рефакторинг с AI начинается с фиксации поведения. Сначала нужны тесты или хотя бы список проверяемых -сценариев. Затем изменения делаются механическими шагами: переименование, выделение функции, перенос логики, удаление -дублирования. +Сначала нужно зафиксировать текущее поведение тестами, затем выполнять механические шаги небольшими commits и не +смешивать рефакторинг с новой функциональностью. После каждого шага проверяются контракты и поведение. **Полный ответ** -Безопасный рефакторинг с AI начинается с фиксации поведения. Сначала нужны тесты или хотя бы список проверяемых -сценариев. Затем изменения делаются механическими шагами: переименование, выделение функции, перенос логики, удаление -дублирования. +Безопасный рефакторинг меняет структуру кода, сохраняя наблюдаемое поведение. AI хорошо ускоряет механические операции: +переименование, выделение функции, перенос общего кода, замену повторяющегося паттерна и обновление imports. Но модель +может незаметно «улучшить» бизнес-логику вместе со структурой. + +Рабочий процесс: -Важно запрещать модели одновременно менять поведение и структуру. Если поведение меняется, это уже не чистый -рефакторинг, а отдельная задача с другими рисками и проверками. +1. Описать инварианты и покрыть критичные сценарии characterization tests. +2. Выбрать один вид преобразования и ограничить область файлов. +3. Попросить агента не менять публичные контракты и поведение. +4. Выполнить преобразование маленьким commit. +5. Запустить тесты, typecheck и сравнить diff с заявленным шагом. +6. Только после стабильного состояния перейти к следующему преобразованию. + +Например, при переносе вычисления из компонента в service сначала фиксируют входы и выходы тестом, затем переносят код +без изменения правил, и лишь отдельной задачей оптимизируют caching. Если все сделать одним prompt, будет трудно понять, +что вызвало регрессию. + +Ограничение метода в том, что тесты могут не покрывать реальное поведение. Поэтому для рискованных изменений нужны +production telemetry, ручные сценарии, canary или поэтапное включение. На интервью полезно отдельно сказать: если вместе +со структурой меняется бизнес-результат, это уже не чистый refactoring, а функциональное изменение с другими критериями +приемки. @@ -479,20 +656,34 @@ commit остается у инженера. **Короткий ответ** -AI полезен как помощник для поиска сценариев и черновиков тестов. Можно попросить его: +AI полезен для поиска сценариев и подготовки черновиков тестов. Но инженер должен проверить, что тест фиксирует +требуемое поведение, а не повторяет текущую реализацию или предположения модели. **Полный ответ** -AI полезен как помощник для поиска сценариев и черновиков тестов. Можно попросить его: +AI ускоряет тестирование в двух местах: помогает расширить набор сценариев до реализации и создает первый вариант +тестового кода по существующим примерам проекта. Ему можно передать требование, публичный контракт и несколько соседних +тестов, а затем попросить выделить happy path, ошибки и граничные случаи. + +Практичный процесс выглядит так: -- перечислить happy path и edge cases; -- написать тест по существующему стилю проекта; -- упростить setup; -- найти непокрытую ветку; -- объяснить, почему тест падает. +1. Сначала сформулировать поведение и наблюдаемый результат. +2. Попросить модель перечислить сценарии без написания кода. +3. Отобрать случаи с реальным риском регрессии. +4. Сгенерировать тест в стиле проекта. +5. Проверить, что тест падает при намеренной поломке поведения. +6. Упростить setup и удалить проверки деталей реализации. -Но тест должен проверять поведение, а не повторять реализацию. Перед commit тест нужно прочитать так же внимательно, как -production code. +Например, для формы модель может предложить тесты на успешную отправку, ошибку сервера, повторный клик и сохранение +введенных данных. Инженер должен решить, какие случаи входят в контракт продукта, и проверить, что assertions наблюдают +результат пользователя, а не вызов private-метода. + +Основной риск состоит в том, что модель пишет реализацию и тест из одного ошибочного предположения. Поэтому тесты нельзя +считать независимым доказательством только потому, что они проходят. Полезны review, mutation-проверка, изменение +входных данных и ручная поломка важной ветки. + +На интервью стоит подчеркнуть: AI хорошо расширяет пространство вариантов и снимает boilerplate, но выбор проверяемого +поведения и оценка силы теста остаются инженерной задачей. @@ -504,16 +695,33 @@ production code. **Короткий ответ** -Часто полезнее сначала попросить тест-кейсы. Они показывают, как модель поняла требование, какие риски видит и какие -сценарии считает важными. +Часто полезнее сначала запросить тест-кейсы. Они показывают, как модель поняла требование, какие риски заметила и что +считает корректным результатом, еще до появления большого diff. **Полный ответ** -Часто полезнее сначала попросить тест-кейсы. Они показывают, как модель поняла требование, какие риски видит и какие -сценарии считает важными. +Запрос тест-кейсов до реализации превращает понимание задачи в проверяемый список сценариев. Если модель пропустила +ключевую ошибку, неверно поняла роли пользователей или считает допустимым неправильный результат, это дешевле исправить +в списке, чем после генерации кода. + +Хорошая последовательность для поведенческой задачи: + +1. Описать пользовательский сценарий и ограничения. +2. Попросить позитивные, негативные и граничные случаи. +3. Согласовать expected results и приоритеты. +4. Превратить важный сценарий в failing test. +5. Только после этого предложить минимальную реализацию. +6. Проверить diff и добавить недостающие тесты независимо от модели. -Если тест-кейсы слабые или не соответствуют продуктовой задаче, реализация почти наверняка тоже будет слабой. Хорошая -последовательность: требования, сценарии, тест, реализация, проверка diff. +Например, перед исправлением повторной отправки формы стоит запросить сценарии для двойного клика, медленного ответа, +ошибки сервера и повторной попытки. Такой список сразу показывает, понимает ли модель жизненный цикл запроса. + +Но правило не абсолютное. Для исследовательского spike, незнакомого API или визуального прототипа сначала может +понадобиться маленькая реализация, чтобы выяснить ограничения платформы. После исследования контракт нужно зафиксировать +тестами до превращения прототипа в production-код. + +На интервью сильный ответ связывает порядок с неопределенностью: тест-кейсы сначала полезны там, где важно согласовать +поведение; прототип сначала допустим там, где команда еще исследует техническую возможность. @@ -525,24 +733,36 @@ production code. **Короткий ответ** -Лучше просить не общий список "edge cases", а анализ по категориям: +Нужно дать модели контракт и попросить анализ по категориям: пустые данные, границы, ошибки, права, concurrency, +локализация, accessibility и совместимость. Затем случаи надо приоритизировать по вероятности и ущербу. **Полный ответ** -Лучше просить не общий список "edge cases", а анализ по категориям: +Общий запрос «найди edge cases» часто дает случайный длинный список. Качественный запрос описывает систему, инварианты и +категории риска. Полезно передать типы входа, допустимые состояния, роли пользователей, внешние зависимости и уже +известные ограничения. + +Можно попросить пройтись по нескольким направлениям: -- пустые и отсутствующие данные; -- граничные значения; -- ошибки сети и retry; -- права доступа; -- локализация и Unicode; -- конкурентные изменения; -- медленные устройства; -- accessibility; -- backward compatibility. +- отсутствующие, пустые и частично заполненные данные; +- минимальные, максимальные и переходные значения; +- медленная сеть, timeout, retry и частичный ответ; +- повторные и конкурентные действия; +- разные роли и authorization boundaries; +- Unicode, локали, часовые пояса и форматы чисел; +- keyboard navigation, screen reader и reduced motion; +- старые данные, версии API и backward compatibility; +- отмена операции, cleanup и восстановление после ошибки. -После этого нужно выбрать важные сценарии и превратить их в тесты или acceptance criteria. Не каждый edge case нужно -реализовывать, но важные риски должны быть осознанными. +Например, для изменения даты недостаточно спросить про пустое поле. Важны смена часового пояса, переход через полночь, +летнее время, локальный формат и серверное значение без offset. + +Полученный список нельзя автоматически превращать в требования. Команда оценивает вероятность, стоимость ошибки и +сложность поддержки. Критичные случаи становятся acceptance criteria и тестами, менее важные документируются как +осознанные ограничения. + +На интервью полезно показать метод: сначала дать доменный контекст, затем систематически расширить пространство +сценариев и в конце приоритизировать риски, а не обещать обработать любой теоретический случай. @@ -554,23 +774,35 @@ production code. **Короткий ответ** -AI часто пишет тесты, которые повторяют текущую реализацию, проверяют mocks вместо поведения или утверждают очевидные -детали. Такие тесты создают ощущение безопасности, но плохо ловят регрессии. +AI-generated тесты могут повторять реализацию, проверять mocks и private details, злоупотреблять snapshot или проходить +при сломанном пользовательском сценарии. Высокое покрытие строк само по себе не доказывает качество. **Полный ответ** -AI часто пишет тесты, которые повторяют текущую реализацию, проверяют mocks вместо поведения или утверждают очевидные -детали. Такие тесты создают ощущение безопасности, но плохо ловят регрессии. +Модель часто строит тест по видимому коду, поэтому естественно воспроизводит его структуру. Если функция вызывает +helper, AI проверяет вызов helper; если компонент меняет внутренний signal, AI проверяет signal. Такие assertions +закрепляют текущую реализацию, но могут ничего не говорить о пользовательском результате. + +Тревожные признаки: -Плохие признаки: +- тест продолжает проходить после намеренной поломки важного поведения; +- assertion проверяет число вызовов mock, хотя контракт описывает результат; +- private-методы раскрываются только ради теста; +- snapshot велик и никто не проверяет смысл изменений; +- setup сложнее сценария и скрывает реальные входные данные; +- happy path покрыт несколькими похожими тестами, а ошибки отсутствуют; +- тесты реализации и production-код основаны на одном предположении модели. -- тест проходит даже при сломанном пользовательском сценарии; -- много snapshot без смысловых assertions; -- проверяются private details; -- setup больше самого сценария; -- нет негативных и граничных случаев. +Полезная проверка силы теста — временно внести дефект: удалить guard, поменять условие, вернуть неправильное значение. +Тест должен упасть по понятной причине. Более системный вариант — mutation testing, где инструмент автоматически меняет +код и показывает выжившие мутации. -Хороший тест должен падать, если нарушено важное поведение. +Хороший тест формулируется через публичный контракт: given, when, then. Он устойчив к безопасному рефакторингу и +ломается при изменении важного поведения. Покрытие строк и количество тестов используются как вспомогательные сигналы, а +не как цель. + +На интервью стоит объяснить, что AI снижает стоимость генерации тестового кода, но одновременно повышает риск большого +объема слабых тестов. Поэтому review тестов должен быть таким же строгим, как review production-кода. @@ -582,23 +814,35 @@ AI часто пишет тесты, которые повторяют теку **Короткий ответ** -AI может быстро написать черновик e2e-теста, но доверять ему без проверки нельзя. E2E-тесты часто становятся хрупкими: -зависят от таймингов, неустойчивых селекторов, конкретного порядка данных или внешних сервисов. +AI можно доверить черновик e2e-теста, но не решение о его стабильности. Нужно проверить селекторы, ожидания, тестовые +данные, изоляцию, сеть, параллельный запуск и диагностичность падения. **Полный ответ** -AI может быстро написать черновик e2e-теста, но доверять ему без проверки нельзя. E2E-тесты часто становятся хрупкими: -зависят от таймингов, неустойчивых селекторов, конкретного порядка данных или внешних сервисов. +E2E-тест содержит много неявных договоренностей: как подготовить данные, дождаться интерфейса, найти элемент, +изолировать пользователя и понять причину падения. Модель может быстро собрать рабочий happy path, но часто использует +хрупкие CSS-селекторы, произвольные timeout и зависимость от состояния общей среды. + +Перед merge нужно проверить: + +- используются ли role, label, test id или другой устойчивый user-facing selector; +- ожидание связано с наблюдаемым состоянием, а не с `waitForTimeout`; +- данные создаются и очищаются предсказуемо; +- тест не зависит от порядка других тестов; +- network-запросы контролируются или корректно ожидаются; +- сценарий выдерживает параллельный запуск и повтор; +- trace, screenshot и текст ошибки помогают найти причину; +- проверяется пользовательская ценность, а не только факт клика. -Что проверить: +Например, тест входа не должен искать `.button:nth-child(2)` и ждать две секунды. Он может найти кнопку по роли и имени, +дождаться ответа или изменения URL и проверить доступный пользователю результат. -- используются ли user-facing selectors; -- нет ли произвольных timeout; -- контролируются ли network и test data; -- тест проверяет реальный user flow; -- падение будет понятно по ошибке и trace. +Не каждый сценарий стоит поднимать до E2E. Если правило надежнее и быстрее проверить unit- или integration-тестом, +добавление E2E увеличит длительность и flaky rate без достаточной пользы. E2E оставляют для критичных сквозных +контрактов между слоями. -AI хорош для первого варианта, но стабильность e2e-теста остается инженерной задачей. +На интервью хороший ответ: AI ускоряет первый вариант, но инженер отвечает за уровень теста, стабильность синхронизации, +данные и диагностику. Доверять можно процессу с проверками, а не тексту генерации.