Как программировать с помощью ИИ
ИИ может исследовать проект, предложить план, изменить код и запустить проверки. Надежный результат начинается с точной задачи и заканчивается ручным просмотром diff, а не ответом в чате.
Какой сервис подходит под рабочую среду
Подсказки, агент, pull request и правила команды.
AI-first редакторCursorМногофайловые правки и checkpoints в отдельном редакторе.
Работа из терминалаClaude CodeИсследование проекта, команды и Git из CLI.
Локально и в облакеOpenAI CodexCLI, IDE, приложение и отдельные облачные задачи.
Параллельные агентыGoogle AntigravityПроекты, worktree и несколько локальных задач.
Разработка по спецификацииKiroТребования, дизайн и список задач перед реализацией.
Open source в терминалеAiderGit-процесс и выбор поставщика модели.
JetBrains IDEJetBrains JunieПланирование, инспекции IDE, команды и тесты.
Приложение в браузереReplit AgentСборка, инфраструктура и публикация в одной среде.
Шесть шагов от задачи до готового изменения
Опишите результат
Укажите задачу, критерии готовности, ограничения и что менять нельзя.
Дайте контекст
Передайте структуру проекта, нужные файлы, инструкции и команды проверки. Не добавляйте секреты.
Попросите план
Для сложной задачи сначала получите короткий план и список рисков без изменения файлов.
Ограничьте diff
Разрешите небольшое самостоятельное изменение без случайного рефакторинга соседнего кода.
Запустите проверки
Нужны автоматические тесты, lint, typecheck и проверки безопасности, которые уже приняты в проекте.
Проверьте человеком
Просмотрите diff, поведение, зависимости и миграции. Только после этого объединяйте изменения.
Промпт для изменения в существующем проекте
Изучи репозиторий и добавь [функция]. Критерии готовности: [список]. Не меняй [ограничения]. Сначала покажи короткий план. После согласования сделай минимальный diff, добавь или обнови тесты, запусти [команды проверки] и перечисли измененные файлы, результат проверок и оставшиеся риски.
Что нельзя отдавать агенту без необходимости
Не вставляйте API-ключи, пароли, production-конфигурацию и персональные данные в запрос. Ограничивайте доступ к терминалу, облачным ресурсам и внешним системам конкретной задачей.
Даже если агент сообщил об успешных тестах, откройте diff и проверьте команды самостоятельно в доверенном окружении. Ошибка в коде, миграции или инфраструктуре может проявиться позже.
Разработка с ИИ через ограниченный контекст, небольшой diff и проверку поведения
Полезный запрос к помощнику похож на задачу для разработчика: текущее поведение, ожидаемый результат, границы изменения и способ проверки. Чем больше несвязанных файлов и требований передано одновременно, тем труднее увидеть ошибочную предпосылку. Работу лучше вести короткими изменениями, каждое из которых можно прочитать и откатить.
Паспорт задачи до изменения кода
Наблюдаемая проблема
Приведите минимальный пример, фактический и ожидаемый результат, окружение и точный текст ошибки. Не заменяйте описание предположением о причине.
Граница репозитория
Укажите затрагиваемый модуль, публичные интерфейсы, версии зависимостей и файлы, которые нельзя менять. Передавайте только необходимый контекст без секретов и пользовательских данных.
Критерии приемки
Запишите сценарии успеха, негативные случаи, требования производительности, доступности и совместимости. Определите команды тестов и сборки, которые должны пройти.
Ограничение изменения
Задайте допустимый размер diff, запрет на новые зависимости или миграции и необходимость сохранить обратную совместимость. Большую задачу разделите на последовательные шаги.
Что должно быть истинно перед merge
- Diff ограничен задачей, не удаляет пользовательские изменения и не содержит форматирования несвязанных файлов.
- Новый тест падает на прежнем поведении и проходит после исправления либо есть другое воспроизводимое доказательство причины.
- Проверены нулевые, пустые, предельные и ошибочные входы, а сообщения не раскрывают секреты и внутренние детали.
- Типы, lint, целевые и полные тесты, сборка и необходимые ручные сценарии проходят в чистом воспроизводимом окружении.
- Документация, конфигурация и миграции обновлены там, где меняется внешний контракт или порядок развертывания.
Сигналы опасного изменения
Исправление просто ловит и игнорирует ошибку
Вернитесь к источнику некорректного состояния. Ошибку либо обрабатывают с понятным результатом, либо передают выше; пустой catch скрывает дефект и затрудняет наблюдение.
Патч добавляет зависимость ради нескольких строк
Проверьте стандартную библиотеку и существующие утилиты, оцените размер, лицензию и обслуживание. Новую зависимость принимайте только при явной пользе и проверенном lock-файле.
Тест повторяет реализацию и всегда проходит
Проверяйте внешнее поведение и важные побочные эффекты, а не внутренние вызовы без необходимости. Добавьте случай, который действительно отличает правильный результат от прежней ошибки.
Пять контрольных точек реализации
Сначала исследовать
Попросите найти поток данных, владельца состояния и существующие тесты, не меняя файлы. Сверьте план с архитектурой и убедитесь, что причина подтверждается кодом или воспроизводимым экспериментом.
Согласовать минимальный план
Перечислите файлы и ответственность каждого изменения. Отдельно отметьте риски, миграции и альтернативы. Если план затрагивает несвязанный модуль, сократите область до причины.
Внести один логический diff
Изменяйте небольшой участок и сразу просматривайте патч. Не принимайте массовую переработку ради локальной ошибки, переименование публичных API без запроса или скрытое подавление исключения.
Проверить тестами и наблюдением
Запустите целевые тесты, затем полный набор в соответствии с риском. Для интерфейса проверьте состояние загрузки, ошибку и пустые данные; для API - статус, схему и повторный запрос.
Провести ручной review
Ищите неправильные допущения, гонки, утечки данных, граничные значения и несогласованную обработку ошибок. Сравните реализацию с критериями, а не только с зеленым тестом.
Описание изменения для review и релиза
Передавайте краткую причину, выбранное решение, список файлов, риски и точные команды проверки. Приложите результат воспроизведения до и после, сведения о миграции и способ отката, если изменение влияет на данные или трафик. В описании релиза отделите видимое пользователю поведение от внутренней переработки. Ревьюер должен понять контракт и проверить diff без истории чата, а дежурный - диагностировать проблему по логам и метрикам.
Исправление ошибки без случайной смены поведения
Возьмите небольшой обработчик формы с воспроизводимой ошибкой: пустое поле принимается как корректное. Запишите вход, ожидаемый ответ и текущий ответ до обращения к ИИ. Передавайте только нужный фрагмент кода без секретов и личных данных пользователей.
Как провести пробу
Попросите объяснить причину и предложить минимальную правку. Сначала добавьте проверку, которая воспроизводит ошибку, затем внесите изменение. Проверьте пустую строку, строку из пробелов, нормальное значение и случай с очень длинным вводом. Просмотрите diff: генератор не должен незаметно менять соседние правила формы.
Что считать готовым результатом
Исправление принято, когда исходная ошибка исчезла, а прежние допустимые значения продолжают работать. Если ответ модели зависит от несуществующей библиотеки или обходит валидацию только на клиенте, пересмотрите решение. Для важных данных повторите проверку на сервере.
Что сохранить для следующей правки
Сохраните минимальный пример, тест, diff и описание риска. Другой разработчик должен понять причину изменения без чтения всей переписки с моделью.