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

Как программировать с помощью ИИ

ИИ может исследовать проект, предложить план, изменить код и запустить проверки. Надежный результат начинается с точной задачи и заканчивается ручным просмотром diff, а не ответом в чате.

Проверено 15 августа 2026 годаМы не проводили самостоятельные тесты качества кода. Возможности и условия доступа взяты из официальной документации.

Быстрый выбор

Какой сервис подходит под рабочую среду

IDE и GitHubGitHub Copilot

Подсказки, агент, pull request и правила команды.

AI-first редакторCursor

Многофайловые правки и checkpoints в отдельном редакторе.

Работа из терминалаClaude Code

Исследование проекта, команды и Git из CLI.

Локально и в облакеOpenAI Codex

CLI, IDE, приложение и отдельные облачные задачи.

Параллельные агентыGoogle Antigravity

Проекты, worktree и несколько локальных задач.

Разработка по спецификацииKiro

Требования, дизайн и список задач перед реализацией.

Open source в терминалеAider

Git-процесс и выбор поставщика модели.

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 без истории чата, а дежурный - диагностировать проблему по логам и метрикам.