ИИ-программист: кто пишет и проверяет код

Как выбрать инструмент

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

Cursor устанавливается на Windows, macOS или Linux. Он видит файлы проекта, может предложить изменения в нескольких местах и работать с терминалом. Это не хостинг: после правки приложение нужно собрать и опубликовать вашим обычным способом.

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

Интерфейс обоих сервисов английский, оплата указана в долларах. По данным карточек SHEER, Cursor из России обычно требует VPN, а Replit обычно открывается без него.

Где живёт проект

CCursor

• •ЗадачаИсправить баг в существующем проекте
• •КонтрольДифф, тесты и история git

RReplit

• •ЗадачаСобрать прототип с адресом в интернете
• •КонтрольКод, база, доступ и расходы на хостинг

Как поставить задачу

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

Пример: «В checkout.js скидка применяется второй раз при повторном вводе того же промокода. Исправь только расчёт скидки. Не меняй платёжный модуль. Добавь тест: итоговая сумма после повторного ввода не меняется. Сначала покажи план и затрагиваемые файлы».

Перед запуском полезно указать:

• где находится проблемный код;
• как воспроизвести ошибку;
• какой результат считается правильным;
• какие файлы и зависимости нельзя менять;
• какие тесты нужно добавить или запустить;
• нужно ли сначала показать план без правки файлов.

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

Примеры задач для агента

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

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

Для прототипа в браузере: «Собери закрытую страницу учёта заявок с входом администратора. Поля: имя, телефон, источник и статус. Нужны создание, редактирование и поиск. Сначала покажи модель данных и список страниц, публикацию не запускай до подтверждения».

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

Как проверить изменения

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

Затем запустите автоматические проверки проекта:

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

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

Не принимайте непонятный код только потому, что приложение запускается. Попросите упростить решение или объяснить каждое изменение. Поддерживать этот код после публикации будет команда, а не ответ в чате.

Как проверить правку агента

1. 1ДиффИзменены только нужные файлы
2. 2ТестыСоседние сценарии не сломались
3. 3Отдельная веткаНебольшие коммиты
4. 4ОбъединениеПосле просмотра файлов и конфигурации

Когда нужен ручной просмотр другого разработчика

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

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

Как работать с секретами и зависимостями

Не вставляйте API-ключи, пароли, токены доступа и данные клиентов в текст запроса. Секреты хранят в переменных окружения или встроенном хранилище платформы. В коде остаётся только имя переменной, например PAYMENT_API_KEY, без реального значения.

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

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

В Cursor режим приватности доступен и на бесплатном плане. Для команды его настраивает администратор. Но настройка приватности не отменяет внутренние правила компании: закрытый код и клиентские данные передают внешнему сервису только с разрешения.

Как подготовить публикацию

Работайте в отдельной ветке и делайте небольшие коммиты. Перед объединением правки просмотрите список файлов, результаты тестов и изменения конфигурации. Если агент одновременно обновил зависимости, форматирование и бизнес-логику, разделите это на понятные части.

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

Перед публикацией:

1. соберите приложение в чистом окружении;
2. запустите тесты;
3. проверьте критический сценарий вручную;
4. убедитесь, что секреты не попали в код и логи;
5. подготовьте способ отката;
6. после выкладки проверьте основные страницы и ошибки.

GitHub Copilot полезен для подсказок во время набора, а чат - для объяснения небольшого фрагмента. Для изменения нескольких связанных файлов нужен контекст проекта. Независимо от инструмента, одинаково важны дифф, тесты и понятный план отката.

Что не стоит полностью делегировать

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

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